So I am a beginner in using agile frameworks and came to Munich for LeSS Conference for one purpose only – to find out how to quickly and effectively and painlessly make use of the framework in my own context. Simple, right?

I knew there would be a lot of inspiration – and there was! Thank you all content givers! I knew there would be many interesting discussions about different implementations in details or specific problems on the way or discovering the mindset it is great to manifest – and there were! (Some discussions/presentations ended up standing because of hot topic) I expected many experienced, positive, I-know-why-I-came people to meet and to stay in touch afterwards and I wasn’t disappointed. Finally, I hoped for great food ;) and it was de-li-cious (though still… less is more).

I also have learned that silent high five actually works for big conference, that (piano) keyboard is not designed for one player only (and pattern „one keyboard – one screen – one developer” is only my heavy bias) and that bully hen was a great team player 6 generations earlier, so promoting good teams as a whole is far better than promoting individuals in the long run.

It is with much trepidation and anticipation, that I decided to make the pilgrimage to Munich to attend this year’s LeSS Conference at the Paulaner am Nockherberg that happened between 12th to 13th of September, my very first. I know myself enough that travelling anywhere that wrecks havoc to my bio-clock has typically turned out torturous and eventful for me. However, I am curious as to what to expect and what I can gain attending THE annual LeSS event. There is a lot that I know that will put me into my uncomfortable zone - a brand new place I have yet to visit, a country with a language I do not speak, fresh new faces with people from countries and cultures very different from what I have grown used to in my 40 odd years growing up in Singapore.

We booked an Airbnb place, near-ish from the conference venue. I was warmly received by my Shanghai colleague, Joseph, on the early morning of 9th September, who waited at the train station, which is close to where he stays, and happens to be a short walking distance from where he currently coaches - BMW; Incidentally BMW is presently, undergoing a huge organisational transformation, to adopt LeSS, and find a better approach towards product development for their Autonomous Driving Program.

Last week I had a pleasure (and pain :)) of attending Less Conference in Munich. Here are a few words why it is such a great experience and why I would recommend it to anyone working within a team.

(by Bas Vodde and Craig Larman)

On Product Manager in the Team

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?

(by Bas Vodde and Craig Larman)