Look at Capability, not Title.

Ever since Scrum became widely adopted in the early 2000’s, discussions have arisen whether the Scrum Team consists of programmers, designers, or other titles specific to the needed skills. Should they be called out by title, or is this a cross-functional team?

With the arrival of Dev/Ops, a surge of opinion pushed that Developer team should be replaced with Delivery team, especially for non-software development (like marketing). Yet, from a Scrum user’s (Product Owner?) point of view they are everyone and anyone necessary to research, develop, deliver, and sustain the increment.

This has unearthed strong opinions. Unfortunately, they don't converge on a single word or phrase.

A Developer is on the Scrum Team … we have listened to discussions about where this leaves the architect, tester, infrastructure setup, and other non-programmers required to “create”  a “Done” increment.

Check this link

While bringing any change in the organisations, the focus should be on changing the mental model of the system. This, in turn, will change the subsequent actions resulting in the new behaviours. In my past, I have observed too much focus was given on changing the language and I found it’s ineffective. For example, enforcing people to replace “humans” with “resources” or “Iteration manager” with “Scrum master”. I realised that even after this “enforcement”, “people” were still treated as resources as the mental model didn’t change. I come to believe, Mental models, precede language and not the other way around.

Check this link

 

Prefer decentralised coordination rather than centralised co-ordination

If you are a LeSS Practitioner, you might have heard this before..
 

Teams Own the Coordination

In LeSS, the coordination and integration is owned by the teams, rather than by a separate group such as the “project management team” or “integration team.” Meaning?

Each team is responsible to coordinate with other teams to ensure one integrated product increment that can ship at least once per Sprint. Why is this important?

> puts responsibility for coordination & integration decisions and actions with the people doing the hands-on work

> supports the teams owning their processes—and then improving

> reduces delays and handoff

> reduces organizational complexity—no special roles needed

Prefer Decentralized over Centralized Coordination

Centralized coordination techniques are scheduled meetings with people from all teams together, such as Scrum of Scrums, Town Hall meetings, or a project status meeting (often re-badged with an agile label, but no different). Some weaknesses? They increase bottlenecking of information, handoff, delay, “it’s not my problem” behaviors, and... can be incredibly boring!

Decentralized coordination techniques don’t require a central meeting or group, and encompass networks of people interacting. For example, teams working in a shared space and talking, or multi-site teams discussing through a chat tool. They avoid bottlenecks, handoff, delay. But a few drawbacks: getting an overview—to see if issues are falling through the cracks—is more difficult; and information about the overall system is less broad and less consistently shared.

In favor of decentralized methods, they underpin more emergent behavior for coordination, and in LeSS this emergence is encouraged. Why? In large systems centralized and prescribed methods of coordination can inhibit (1) empirical process control and continuous improvement, and (2) teams having a sense of owning these processes.