This post is the second in a series related to product management and product teams. Like the previous post, this one is partly influenced by Marty Cagan’s article on “Product Teams” vs “Feature Teams”. Marty seems to see the role of Product Manager different than we do, but the difference is probably more about the team than about the Product Manager. That said, this post is especially influenced by the frequent recurring question, “Should a Product Manager be on the Team?”
Being on the Team in LeSS
First, let us clarify that a little bit by exploring what “part of the Team” means in LeSS.
The Team has a shared responsibility for the result of a Sprint. A shared responsibility means that, even though people on the team probably have a primary specialization and a preferred focus area (which may not be the same, because of learning), all of the members of the team are responsible for all the work that the team does. In practice, this results in vague boundaries between the individual team members primary specialization, and in some teams not even a meaningful distinction.
A Team in LeSS (and Scrum) is also self-managing. What’s the implication of that on a team taking a shared responsibility? Key point: the team will need to have (1) a clear shared goal, (2) at the same time. We want to stress the temporal aspect here as it is rarely discussed but really important! When a new self-managing team is formed in which previously the team members were used to traditional siloed single-function roles, then if they continue that pattern, the team will struggle with finding ways to parallelize their work. The first and easiest questions is, how can we test before the implementation is done? Then, the same question needs to be answered related to the other roles that used to work in a sequential lifecycle with handoff, “How can we do the UI design at the same time as the implementation?”, “How can we do the analysis at the same time as the implementation”.
The fundamental problem that self-managing teams with shared responsibility have to solve is: How can we together in parallel work on activities that were previously considered sequential?
What would it mean if the Product Manager were part of the team?
When a Product Manager is part of the team, it will mean that the Product Management responsibilities are a shared responsibility within the team. However, one problem to solve here is that a significant amount of Product Management activities usually do not – or even can’t – happen at the same time as the activities of the rest of the Team for the selected work in the Sprint. This is mostly because of the delayed feedback of some of these activities. For example, if a Product Manager is out observing users or talking with them, then this activity is usually not at the same time and for the same goal as what the team is working on right now.
Just to be clear, we are not saying that it’s good that Product Managers don’t work on the same goals at the same time as the Team, we are simply observing that this is often so, and that it’s hard to change that in the context of the customers they work with and the organization they work in.
Considering this, we have seen two common alternatives of Product Management working with the team:
Product Manager as part of the team
This means the whole team takes on Product Management responsibilities (not just the person with Product Management preference). The team together discusses how to get closer to customers, understand them better, emphasize better, and discover potential new outcomes to achieve or new features to create.
It is likely to happen that the Product Management activities do not directly relate directly to the other work selected in the Sprint. In that case, the team needs to cope with the temporal differences, the work selected in the Sprint and the Product Management responsibilities related to understanding the customer, without creating separate roles within the team. For example, the entire team gets together at the beginning of the Sprint (Sprint Planning 2) to understand the Product Management activities and decides how they together are going to work on these.
Note that there is a similarity and overlap between Product Management activities and Product Backlog Refinement. Product Backlog Refinement is similar look-ahead work. A difference is that it is often possible to do Product Backlog Refinement work with the entire team together while it might not be feasible to always send the entire team to the customer (though maybe that’s not a bad idea…)
Product Manager who works with a team
Although in LeSS we love the Product Manager – and hence Product Management responsibility – to be part of the team, in practice we often see a Product Manager working with teams. In this case, the Product Manager focuses on Product Management activities (such as competitor and market analysis, and much more) and helps the teams to understand the market, customer, and problems to solve. Sometimes a Product Manager might work very close with one or several teams for a long time when the team works with customers or features that they know most about. However, in that case the Product Management responsibilities are not (yet) fully shared within the team.
In some cases, this is a first step to eventually moving the Product Management responsibilities into the team. In other cases, that won’t happen because (1) the focus of the team changes whereas the focus of the Product Management might not (e.g. in case the Product Manager is focused on a particular customer or customer segment), or (2) the Product Manager’s responsibility is intrinsically hard to share in the team, which might be the case when there’s lots of travel and customer relationships that needs to be maintained.
Conclusion
So, should the Product Manager be a part of the team? Which also means, should Product Management be a shared responsibility in the team? If you can do that, great! Alternatively, Product Managers can work with the team to help them understand the customers better.
On the Product Owner Role
Final note: We are talking about Product Management here and not the role of Product Owner. In LeSS, the Product Owner focuses on overall Product vision, prioritization, and investment decisions. In product companies, the Product Owner tends to be one senior person from a Product Management group, but not all Product Managers will be Product Owners.
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.
RSS feed