References & Assets To Share


17 thoughts on “References & Assets To Share”

  1. Avoid…Product Manager is not Product Owner 120 (135)

    Avoid… Product management or Product Owner
    between teams and users 146-147 (161)
    Avoid… Multi-level P-M indirection from customers
    to teams 146 (161)

    Try… Maintain three levels when using Area Backlogs 221 (236)
    Try… Three Levels Max 222 (237)

  2. Top 5 Questions for this Friday:

    Organizational boundaries for the LeSS adoption: why organizational boundaries are so important? Have you faced the problems of people, attempting to define products AROUND traditional organizational design and command & control, as oppose changing organizational design to support product centricity?

    Product Owner (PO) to Area Product Owner (APO) relationship: was it based on traditional organizational reporting structure or something else? More details on this are appreciated.

    Parallel LeSS Organization: what are the main challenged that were faced, when creating a parallel organization? Any pushback from executive management? If ‘yes’, why?

    Competence and Coaching Department: what was its organizational alignment within the org structure. Please, provide more details about figure 15 (

    What are some of the most common mistakes you have seen/made/avoided, with respect to expanding product definition?


    XXXXX shares his experience of working with a large health care organization where he worked with leaders and 35 teams to move from being project based to becoming product centric that keeps the customer in mind. Influenced by LeSS-Huge this organization made significant changes including getting to one product backlog, one product owner, self-designed teams, feature teams, and much more.

    its the usual stuff. Must have authentic executive ownership where they do some of the work.
    Must train a lot of people to build shared vision / ownership
    Having a good change plan is key to help with transparency so everyone is in the loop and not left guessing about what is happening, why its happening and when things will happen
    “people side of Change” providing session for people to develop personal and team skills on how to navigate the change
    reorganization – how the value of empowerment comes when you remove manager levels, etc.

    Being sure we do a self designing team workshop followed by the Initial PBR for a few days. These are key to the overall buy in, empowerment, showing of trust, etc.

    Upskilling plan/ effort to help our “m-shaped” efforts to give people time to learn and grow within the team / space and to not be generalist. and the effort be tied to what is needed now, plus to support the modernization strategy like test automation and CI being started. CD later.
    Defining career paths when you move all roles onto the teams like the BA, UX and QA people. and then to show them a path to learn new skills

  4. Thanks for sharing Deniz.
    Replying to both of your emails here.

    You certainly should not change your stance, particularly, with respect to your expectations of the team and their capabilities. Some of my comments below could help you with crystalizing your position even further. Some of the replies to your questions below (the exchange was back in November), also add to my own scepticism.

    What you heard from James would be consistent with my expectations. As a coach, I usually make an extra effort to make people non-theatened by my appearance. My hope is always to enable and support Scrum Masters (often times, coaching from the ‘back of the room’).

    As mentioned, the argument: “we do XP and therefore we don’t do Scrum” is a false dichotomy. We absolutely want such dev practices as XP to be a part of Scrum (and LeSS). This is easier to graps, if LeSS (and Scrum) are not viewed ‘agile methodologies’ but rather, as organizatinal design frameworks. But this is minor because it clearly says here that there would be no issues to use XP inside them. True. XP, as an engineering practice can and should be used in both: Scrum and LeSS.

    All three of you sat through my class and know first-hand what we have covered, how much attention we pay to org design and other ‘untouchable’ areas (I must also admit that many ‘tactical’ discussion we cannot get to in class, due to time limits). Then you may judge for yourself, how effective it would be, to have internal people teach other internal people intricacies of org design, touching so many sensitive topics.

    This would be concerning to me. There no even such role in XP: “PM”. (XP roles: developer, customers, xp-coach, tracker). As mentioned, the one and only slide that I was able to capture from Deniz, titled “Day in life of a product manager” – raised some red flags for me. This role sounded too much like conduit/translator/delegate/proxy/”team-level helper” that sits between a PO (Natasha) and developers. Usually, a traditional BA or manager is given this role, to be kept busy and ‘shield’ developers from talking to users’. I also suspect that the role of a PO is not well understood. Lastly, faik, Natasha has a few trusted helpers (Lauren, Colton), to help her along.

    Here, I am at odds, how much vetting and thinking was put into assigning SM to the team? Sounds like “you want SM, we will get you SM”.

    Very similar with what you would observe in SAFe or other, more traditional ways of working: a few special people (tech leads, architects) are deeply immersed in discussions with a PO and users, whereas the rest of the team do not get this opportunity and are just expected to code-code-code.

    The answer “we do pair programming” does not really answer the original question. At least, I would expect the answer to be: “we prefer a client to interview our programmers in pairs”. But even then, pair programming does not mean that the whole team breaks up in persistent pairs and pairs work separately. On-contrary, criss-crossing and cross-polination is desirable (sometimes, referred to as ‘promiscuous programming’ :)).

    I do not think that the question in scope is about ‘separate products’. Guided Selling is – one single product. If only one additional team is needed then any of the suggested approaches could work, assuming that when an initial team splits, each half retains all of the knowledge required to healthily grow back in size. This implies that ALL members of the original team are truly full-stack.

    Gherkin is the lay-man’s (simple) language for Cucumber (latter could be swiftly intergrated with Selenium or other interfaces that allow writing test scrips for most commonly used languages), to write tests in English, using a very simple format (given, when, then & and) – something that non-developers can uderstand. Granted, this is a great XP engineering practice that is stronly promoted in Scrum, along with CI/CD, unit testing, spec by example, clean code practices, etc. This is also fundamental in LeSS
    With that, if CIC folks are so adamant about following XP, they should have on stand-by a very seasoned, XP and/or TDD coach – a hands-on developer, who would be teaching every team member this engineering practice (note: not a dedicated one or two people – the whole team).


Leave a Comment

Please help us fight spam. Lets make sure you are not a robot !!!