This post has its origins in a post by Marty Cagan at https://svpg.com/product-vs-feature-teams/ in which he compares what he calls “product teams” with what he calls “feature teams.” We’re not quite sure where Marty’s definition of “feature team” originates from, as what he calls “product team” seems to be more like a feature team to us than his definition.
That said, the article is strong even when some of the reasoning is weak.
Weak Reasoning
logic weakness - Marty sets up his own definition of feature team (a straw man) and argues against his own definition; i.e. an argument from false premises.
logic weakness - Notice how the article’s argument is framed: either (1) you have “product teams” that are empowered and focus on outcomes, or (2) you have “feature teams” that aren’t. This is an example of the “false dichotomy” logic/argument fallacy, so widespread that we highlighted seeing this as a major thinking tool in the first LeSS book. And of course our suggestion is to consider more options beyond the false binary. For example, here’s a radical idea: How about a team in a large product group that can either be empowered to focus on an outcome with their own innovative discoveries, or that can take on a presented feature request and implement it? Mind… blown!
term weakness - Perhaps the name “product team” is more attractive to you. But notice that the name strongly suggests – although we acknowledge it doesn’t enforce – to the naive ear the idea that the team is creating their (narrow) product. For a fresh 7-people start-up with one team working on the Product, this is fine. For a growing start-up or a larger organization, these many narrow small “products” leads to a profound sub-optimization at the global level in terms of working on highest value, the switching cost of adapting to work on another existing “product”, lack of global vision and alignment, and difficulty of multiple teams to work together on a larger broader product.
You might think, it is just a term. But if you work for a long time in organizational development, you will notice that the choice of terms and the widespread misunderstandings that will arise from those choices is more influential than you might have imagined. We predict that “product team” will easily over time and space get misinterpreted as “each team has a product.”
Note: “feature team” suffers from similar weaknesses, as Marty’s article proves. The main reason for sticking to the term “feature team” is historical. The original use of the term in in Microsoft’s Visual C++ v1 and Ericsson’s AXE basestation – two wildly successful products. Also, we keep using the term because of our failure to find a better one.
Strong Points with which We Heartily Agree
That said, beyond these weaknesses, the article is reasonably good and there are some points that are really important and with which we strongly agree:
The article reminds everyone of the importance of focus on the customer. Teams involved in building great products need to focus on the customer, understand the customer, live the customer.
It reminds everyone the most productive feature teams focus on outcome and not on output, and with the freedom to innovate to achieve the outcome (thus the LeSS Guide: More outcome, less output). Teams become much stronger when you give them problems to solve than when you give them tasks to implement.
It raises some important Product Management dysfunctions that we also frequently encounter.
The article also raises some other questions, which we will discuss in a follow up post. Specifically the question on whether a Product Manager should be a part of the Team. Unfortunately, the answer isn’t trivial and hence another post… “On Product Manager in the Team.”
This article was written for the Japanese translation of the LeSS book. The Japanese translation was added after the English one
Intro to Japanese edition of Large-Scale Scrum (English)
I still remember the first time I visited Japan about 15 years ago. For a European, who was living in China at the time, Japan was a different planet. Trying to understand Japan has taught me a lot about the country and myself… and LeSS. I’m grateful for this and would like to share a few of these learnings.
Respect for people
Having lived in several countries and traveling much too much has increased my interest in national culture. About ten years ago, I decided to explore the effects of national culture on agility. I read everything I could find about national culture. One of them was a book called “dealing with the Dutch.” The book explained Dutch culture to expats living in Holland. Something it mentioned, which I hadn’t realized but is probably very true, is that Dutch people cannot stop have an opinion. Even worse, they always want to share (force?) their opinion with others. They do this in a very direct way, which many Dutch consider to be transparent and honest.
I never doubted that the Dutch directness equates honestly until I lived in China and worked in Japan and Korea. These experiences made me realize that the Dutch directness is not honesty but probably rudeness. Dutch people are so consumed with expressing their opinion that they forget to consider the person they are expressing that to. They don’t take the other person into account.
A couple years ago, I visited a traditional Japanese company. I don’t Japanese and they didn’t speak English, but my colleagues said it is good if I’m there. They gave me detailed instructions on what to say, where to sit, where to watch, and what to do. The amount of conventions that I had to follow made me very uncomfortable. But in retrospect, all of them were about showing respect. Showing respect to the people you are visiting, talking to and working with.
Respect for People is one of the Lean pillars and originates from the Toyota Production System. I don’t think I would have understood that principle in the same way without having spent significant amount of time in Japan. I still have a vivid memory I have is watching a Japanese woman apologize to a beggar on the street that she isn’t able to give him anything. Showing respect, no matter what position you are or whom you are talking to, always respect the people you are talking to. Thanks for teaching me that.
Self-managing teams
Outside of Asia, people frequently ask me whether Scrum works in countries like Korea and Japan. Their reasoning is that Scrum is based on non-hierarchical systems and these countries have strong hierarchical society so it can’t possibly work. However, after spending a lot of time in Japan and Korea, I don’t agree with that reasoning and can clarify that.
A mistake that people make is equating hierarchy with management style. Hierarchy is the amount of power a person gives to a person that is socially above him. Management style is what you do with that power. Hierarchy can help self-managing teams as long as it isn’t combined with a controlling management style.
Hierarchy can help a LeSS adoption. This might feel strange, but makes sense. What happens when you adopt a non-controlling management style in a hierarchical environment? That would mean the manager sets expectations, shares vision, and perhaps set goals… without deep involvement on how people achieve these goals. A hierarchical relationship can benefit self-management because in this case, the team would not request additional instructions as it is clear they are expected to figure it out themselves.
No surprise that Toyota and Lean have a strong team focus. When you read the works of Taiichi Ohno then a lot of his management style is clear in goals and expectations and but not controlling.
Systems Thinking
My last observation that I’d like to share is more recent. The last years I’ve taught a lot of Certified LeSS Practitioner courses in the world. Systems thinking is one of the topics that I cover during this course using systems modeling as one tool. Recently I had a course in Tokyo and two weeks later a course in San Francisco. The difference between the two courses was like night and day.
In the Tokyo course, after explaining the notation of systems modeling and agreeing on a dynamic to model, the people quickly filled up the entire whiteboard. In the San Francisco course, the opposite happened. The people had a hard time agreeing on a dynamic to model, wrote two variables on the whiteboard and got stuck. They would argue about a detail and wondering how to proceed with the exercise. Of course, these are generalizations and are not always true, but still the contrast was surprising.
Why would this be? Of course, I can only speculate and relate to cultural theories that I’m familiar with. Eastern societies are more collective (hence self-managing teams working really well), long-term and holistic while western societies are more individualistic, direct cause-effect thinking, and short-term focused. This domightes clarify the difference in how easy it is to get started using systems thinking.
Conclusion
I’ve visited Japan often enough to say that it is part of me, it has changed me and my thinking forever. I’ve also visited often enough to know that I can never truly be part of Japan. It is a unique society with its strengths and lots of drawbacks. When I didn’t visit Japan for a couple of months, I miss it though and I suspect that I’ll continue to be there regularly for the rest of my life. For LeSS in Japan, I have high hopes. It will go slow and steady but there is a definitive cultural fit. I hope it can help transform Japanese product companies. And personally, thanks to the country and the people for all the insights you’ve given me.
(by Ahmad Fahmy and Craig Larman. Originally published at Scrumalliance.org in 2013)
How long does it take to reorganize to adopt Scrum in an organization? Three hours ;) …
Background and Goal
Bank of America’s Merrill Lynch (BAML) Global Securities Operations Technology decided to adopt Scrum, and needed some changes to do so. Key among those was forming real “Teams” in Scrum: dedicated true cross-functional and cross-component teams of about seven people that could independently perform all the tasks (analysis, development, testing, …) to deliver completely “done” end-to-end functionality.
Before adopting Scrum, the organizational structure was primarily single-function groups (business analysis group, development group, test group). Further, developers were sub-divided into single-software-component subgroups, and there was “private code ownership” in each component group (rather than “internal open source”). Consequently, doing one customer-centric “vertical” end-to-end feature involved massive handoff, coordination challenges, since it would span the business-analysis group, component1-group, component2-group, component3-group, and test group. The silos of component groups resulted in long and difficult integration and regression cycles, leading to a seven-week release-phase.
Therefore, as an early step in their Scrum adoption, the department needed to reorganize the existing groups into new teams – true cross-functional and cross-component (Scrum) Teams.
How to form the new teams, from a total of 35 people? Who should decide the team membership?
People and Traditional Assumptions
As (Ahmad here) an “ex-program manager” in a department moving to Scrum with self-organizing teams who was very interested in the framework and its successful introduction, these questions were present in my mind. I had previously learned of the idea of self-designing teams from our Scrum coach, and considered it an interesting idea, though perhaps not relevant to our situation.
Why not relevant? For one thing, the manager directing the department, at first assumed – we all assumed – that he and the other senior managers would decide the membership of the new teams. This was a default assumption because of our prior culture (and that found in many organizations): managers decide these matters.
But – unknown to me at the time – he (the department head) had had a meeting with the large-scale Scrum consultant and coach who was helping the group, Craig Larman, during which he offered an idea described in the book Scaling Lean & Agile Development: self-organizing team creation or self-designing teams.
Craig shared the story of a department of about 100 people in Hangzhou (China) that was adopting large-scale Scrum, and faced a similar problem:
Instead of deciding on the new teams, the Chinese department manager Lv Yi (along with Bas Vodde, a Scrum expert who worked in the group) invited everyone into a large room, explained the goal of new Scrum teams, and simply asked the group members to decide among themselves. The group agreed it needed four hours for this, and Lv Yi said, “I’ll come back in four hours, and if some people have not decided by then, I will decide.” Four hours later and after much talk and activity, the group had self-designed their new teams. Then, volunteer ScrumMasters were brought to the center of the room, and the teams picked the ScrumMasters that they wanted.
Craig pointed out that this approach was consistent with the self-organizing principle of agile organizations, moving from a command-control management culture to more self-management. He asked, “What does it communicate to the people if managers say, “We are going to adopt Scrum and self-organizing principles”, but then managers decide and tell people what their teams are, and who their ScrumMasters are?” Craig also asked, “And if someone doesn’t like their new team, who will they blame, if the managers decided things, and what action will that disgruntled team member take to fix it? And on the other hand, who will they blame if they themselves decide their teams, and what actions might they take if they don’t like the way things turn out?”
He also suggested experimenting if a team could (internally) “hire or fire” (from their team) their ScrumMaster, rather than one being assigned.
The department head, quickly got the point, and said, “I love the idea! Let’s try it.” Another manager in the meeting seemed open and curious, but also concerned that it might not work out in terms of creating well-balanced teams. To help address this concern, Craig suggested that the session start with an overview (by a senior manager) of the goals and the need for diversity of skills, experience, age, and gender in the teams.
The department head had a bit of reputation as “Mr. Command and Control”, so it came as somewhat of a surprise to many, including myself, when he publicly announced that he was allowing his entire department to self-organize with self-designing teams as part of the Scrum adoption.
The Big Day
The department head scheduled a half-day session for the self-designing teams event, and invited his entire department. He invited me to join the session as an observer. But minutes before the meeting he asked me to facilitate the session rather than merely observe! I agreed.
There was a lot of chatter ahead of the meeting. One of the most seasoned developers quietly pulled me aside before the meeting and expressed his concern to me that he might not be picked. I was taken aback. I thought, the whole thing smells of grade school.
The room in London held 42 people, including 35 future team members, and some ScrumMasters and other observers. The session started with the department head giving an overview of Scrum, though some people had previously been to an introduction with Craig. I could sense that some were not only skeptical of the idea of self-organizing into their own teams, but also of the idea of Scrum in general – primarily those that had not been previously been to a Scrum introduction and did not quite understand the ideas or motivations.
One of the more senior business analysts expressed his concern that Agile would not work for larger groups and may be better suited for small discrete change items. At this point, I interjected and asked the room to vote on their current ability to deliver large-scale change programs, deliver value, and delight the sponsor in our current (traditional) organization and ways of working. The majority voted the current organization’s ability to deliver could be dramatically improved.
At this point, he concluded with two constraints on design of the teams:
teams needed to be co-located
teams needed to be cross-functional and cross-component; they should be able to (or be able to learn to) deliver any item from the Product Backlog
He left after his last remarks, and I was left with many skeptical people in a big room. We had three hours to reorganize a department that had worked within a fixed pattern for decades.
I didn’t have a script to follow, or a formula. Instinctively, I got an idea to run the session as four cycles of 25 minutes, with a five-minute review at the end of each, plus some breaks.
Facilitating Self-Designing Teams
I gave no indication to the already skeptical room that I was making it up as I was going along, let alone the fact that I didn’t believe that this would work. I had discovered long ago that the chances of a new protocol or ritual to be accepted by the hive is much higher if I introduced it as if its been done for years.
I asked everyone in the room to write their name and primary skill on a Post-it note. Four flip chart sheets which would serve as team boards were put up in the corner of the large room. I instructed the group that they had 25 minutes to form themselves into teams. They were all taken aback as they thought they would have three hours to do it. I told them that in this technique no one is allowed to sit for the three hours and one must physically move to the team board. And without further ado, I set the timer and they were off.
Cycle One: “We’re all for improvement, we just don’t want to change anything”
Immediately, cliques began to form based on groups who already worked together. When the “Pomodoro” timer rang, I was a little disheartened. The miracle I was hoping for hadn’t happened. The group had shuffled into their current teams, basically organized by software component. The teams seemed to relish in this, as if to say, “See, we ARE meant to be together.”
I set the timer for five minutes, and we started the first review. I went to the first team and I asked the room for feedback. I noted every defect (variation from an ideal team) on a pink sticky note and put it on the wall next to the team board. This was done fairly quickly and we were able to keep to the five minutes. When finished, each team averaged six defects.
Cycle Two: Celebrating the Courage to Change
Now it started to get really interesting. This is when the group started to get a lot more vocal. I got the sense that people found it very difficult to move around. I wandered around the room trying to help the teams along. Whenever I found one of the more senior members of the team commanding others to go, I would interject and try to facilitate the conversation, with techniques such as the “5 whys”: Why do you need so many X developers? And so on.
Eventually, people in one of the long-established teams said that deciding who had to leave was too difficult, and that perhaps it would be best to invite the manager back to decide. Injecting some harsh humor, I responded with, “Perhaps he can decide what we all have for lunch as well? If we do that we will just be reinforcing the ‘command and control’ culture.” At that point, one of the team members acknowledged they were being ridiculous and volunteered to go to the team that was deficient in his primary skill. I immediately celebrated this fact loud enough so the entire room could hear. This was a bit of a tipping point, and then, finally, other members followed suit.
During the review the teams averaged around two-three defects each. Things were looking a lot better. It felt as though we were finally over the hump and we could get there. Cycle two was complete.
Cycle Three: Ahmad Discovers Another Logjam-breaking Technique
During the third cycle, things slowed down again and people stuck stubbornly to their long-standing teams. There was still an imbalance between two of the teams, one having a surplus of a skill and the other having a deficiency in the same skill.
I proposed that the deficient team physically walk to the surplus team and ask for help. They liked this idea, did it, and were successful. Having seen it work, I asked the other teams to do the same.
Review time. One team had zero defects; the other teams had only two in total. Not bad. I asked the teams to do a sanity check and really “look” at their teammates. This was done and we noticed an imbalance of business knowledge on one team. Once this was corrected, we were nearly done.
Cycle Four: Choosing ScrumMasters and Team Names
The department head and his management team had pre-selected four ScrumMaster candidates. These were chosen based on the profile that was given during Scrum training, as well as on people volunteering for the position. With the department head absent from the room, I decided to modify the situation: I informed the teams that they could select their ScrumMaster from the four names suggested or choose anyone from their own team to be their ScrumMaster. I asked the pre-selected ScrumMasters to leave the room. I gave the teams five minutes to deliberate. In the end, the teams selected from the original candidate ScrumMasters. There was some vying for one of the ScrumMasters, but this was quickly resolved through a silent vote.
We now had four true cross-functional and cross-component newly formed (Scrum) Teams. The mood in the room was good. I decided to inject some humor and finish on a high note by asking the teams to name themselves. This was probably the most animated I saw them on that day, with lots of laughter and lighthearted debate over the names. This too was over in five minutes.
I took a picture of each team under their team name. This made the experience more real for many, including myself.
Retrospective and Wrap-up
I asked everyone to write down positive and negative feedback on the exercise before they left, and this article summarizes their feedback in the appendix.
Once done, the session ended.
I immediately emailed the pictures of the teams to the department and senior management.
This is how a department was transformed in three hours. Now it was on to the business of delivering great software with agility in our world of frequent change and learning.
After this session – and after the subsequent two self-designing events described in the next section – there was one team member swap the day after the session. This was done at the team member’s own initiative, and we view that as a sign of success for the self-organizing team mindset. It is very unlikely that would have happened if a manager had assigned people to teams.
Reflection
Balanced teams could have been created by the management team and in all likelihood they would not be much different from the teams created through this process. A major difference, however, is that the self-designing teams session sets the tone for the cultural change an organization undergoes when properly adopting Scrum. It dismantled many of the command and control constructs early on in a very dramatic way. There was a sense of empowerment at the end of the three hours that was not there before (see Appendix B).
The need for strong facilitation is also vital to run this session smoothly and effectively. An experienced SrumMaster or agile coach is ideally suited to run a session such as this.
Considerable thought needs to be put into whom is in the room. These sessions should not be limited only to technology people, but should include any groups responsible in delivering business value. This is critical as it’s disruptive if team members are “injected” into the teams at a later stage. This can harm the nascent culture that is being created, as well as team morale.
It is important to have a good room environment. For example, the large conference-room table in the room was an impediment and was the number-one complaint (see Appendix B).
Improving the Self-Designing Teams Process: More Experiences
Fortunately, after that first experience, we have facilitated two more self-designing teams sessions within the bank, and have improved the process based on inspection and adaptation.
First, before a self-designing teams event, arrange introductory Scrum education (for example, in a Certified ScrumMaster course) for most participants, so they understand the ideas, motivation, and context.
We have made two major changes to the session and process that we recommend:
The whole group (rather than a manager) defines the ideal makeup of a new team, at the start of the session. Key precondition: They do this based on having been previously educated about true Scrum teams in general, and with teaching and feedback from the facilitator.
ScrumMasters are not pre-selected; rather, the teams vote for their ScrumMasters from a pool of volunteers who have demonstrated knowledge and interest.
The updated session schedule is summarized in Appendix A.
Scaling to 100 team members
After facilitating three self designing team formation sessions, I was recently asked to help facilitate the creation of 14 teams across 100 people. Due to the scale, I did the following:
added another hour to the original format
divided the room into 3 parts and solicited the help of two other scrum masters to help facilitating the review
a pre-defined criteria was provided, but the “room” was giving 25 minutes to overload the team definition rules.
The result was that the team formed an hour early in three hours. The process can indeed scale so long as a scrum master facilitates the review process of no more than five teams.
Summary
Of course, it doesn’t take only three hours to truly and successfully adopt large-scale Scrum; forming the teams in a three-hour session is only one of many obvious and subtle change elements. But it is noteworthy how much can be quickly changed when the organizational will and appropriate hands-on worker and leadership support is in place. And it is noteworthy that with some facilitation, people are quite capable of deciding amongst themselves how to organize into teams, without command-and-control management.
The views expressed in this article are those of the authors and do not necessarily represent the view of, and should not be attributed to, Bank of America.
Appendix A: Potential schedule
Section
Lengh (minutes)
Introduction & Background
20
Ideal Team definition. Define the primary skills required within in any team. This creates a rough guideline, rather a strict rule.
20
Cycle #1
25
Review
15
Cycle #2
25
Review
15
Break
10
Cycle #3
25
Review
15
Team names & Photos
15
Retrospective: “Plus-delta” feedback
5
Conlusion and Next Steps
10
Follow-up session scheduled for the following day to discuss any potential change requests.
Appendix B: Session Feedback
Positive
The process, facilitation & timekeeping, 11
The sense of empowerment, 7
The creation of well balanced team, 8
The sense of team spirit that was fostered, 3
Improvement Areas
Inadequate room choice, 6
Session too long, 5
More management/facilitation involvement required to break deadlocks, 5
Pressure from the “room” applied to join a team you are not happy with, 3
More information required ahead of the meeting regarding individual profiles, session objectives & the type of work teams will be working on, 3
Reluctance of team members to move to leave the initial teams created, 3
This was my very first time in New York. The 16 hours flight from Singapore didn’t make the
conference experience less exciting. I was expecting to see some
skyscrapers, however, got something looking like Amsterdam, hmmm. It’s nice
that the LeSS conference got to keep its style as always. This keeps my hopes up for
the next year LeSS conference in Munich.
The keyword I heard a lot from people describing the conference is “humble”. This is also how I felt. People were sharing their experiences, which were full of courage, failures, surprises, marginal success, and occasional big victories.
I especially liked my ex-boss Tero Peltola’s keynote LeSS Huge at Nokia
(Download Materials). Nokia LTE was the second LeSS adoption Tero did. I was involved as an Agile coach for years. It’s great to see the organizational changes from the most critical stakeholder’s perspective. Don’t miss the session video at InfoQ.
Next, I also liked LeSS Huge at BMW from
Konstantin Ribel and Craig Larman. It’s interesting to see in such a big company as BMW autonomous driving how changes happen both from bottom-up and top-down. The materials are here. The video will be published later in November.
One thing I have been doing for a long time, but still find challenging is Product Backlog Refinement Workshop, especially when it takes more than a couple of teams together. This led me joining Nils Bernert’s
Large group Product Backlog Refinement in LeSS & LeSS Huge. There I got more tools under my belt and learnt different facilitation tricks for splitting and detailing.
Download Materials.
There were 22 planned sessions, together with team-based conference
activities, multiple tracks of open space sessions and panel discussion.
To download the session materials and watch session videos,
please find them in the 2018 New York conference program.
This year Alexey Krivitsky facilitated the self-designing team workshop. This is the initial workshop to form the teams that you are in for the conference. The aim of this is to demonstrate techniques that can also be used in a normal LeSS adoption. Alexey did it in an interesting way. He first let everyone find a buddy and then combined the buddies into teams. For the teams, he tried to maximize the diversity by calculating a diversity index and then have multiple rounds of adjusting. This was an interesting approach as you have one person who you are familiar with and the rest not. I had not experienced this approach before.
I ended up with my buddy Viktor Grgic and in an interesting team which we named “The Team”. Unfortunately, it seems we didn’t make a photo of our team, so I’m not able to share that. However, there were some teams that photo-ed themselves, so some examples,
7 Odd Men
LeSS Out
LeSS Wanted
(If you are reading this and have a team photo that isn’t here, let me know, I’ll add it)
The Conference
During the conference, the team meets up between the session. There they reflect on the session that they went to and share that information with the other team members. Therefore, you get to know something about all the sessions (your team went to). Also, our team would discuss the upcoming session.
Of course, in practice, the team reflection sessions end up to be a lot about not just sharing your conference experience, but about sharing your experience of LeSS adoptions in your company (or not yet). I personally enjoyed the team reflection sessions quite a lot although I missed quite some of them due to interruptions.
Conference Review Bazaar
The conference ends with a Conference Review Bazaar. This is, of course, an instance of a Sprint Review Bazaar in LeSS and we attempt to use similar facilitation techniques to practice those. In the conference review bazaar, the teams first need to work together for an hour to create their conference experience. This could be anything. The most common ones are a flipchart with the summary of the sessions or quotes from the different sessions. Some teams, however, get much more creative and they create a game, a movie, let other people create movies, or whatever they can come up with.
My team, the team, decided to build a huge paper plane and we wrote our learning on post-it notes and put them on the plane. We threw the plane around and also tried to throw it off the balcony. Making the plane was fun but it didn’t turn out to be the best idea as it wasn’t very much showable to the other teams.
The session ended with the Bazaar where all the people visited all the groups to see their creations and learn about their experiences. To make it a bit fun, this is turned into a competition where people can ‘vote’ for the ones they like most. Clearly our plane didn’t win.
Some of the conference review bazaar output photos are below.
Flipchart summaries of the conference
Plank challenge
One team created the plank challenge where you have to do the plank exercise while answering questions. Some photos from that:
Other games
Several other teams created other games, such at the wheels of wisdom:
Some game to pick numbers and colors
Some contest to immitate people
And then this…
In the end, the votes were counted
Closing
All in all, I personally had a lot of learning and fun. It was great to see so much people sharing with each other in a beautiful space. I’m already looking forward to next year (Munich). Thanks to all the participants.
RSS feed