LeSS Lessons Learnt
Scaling Agile, Lean and Scrum to the whole product development department is hard work.
You start a change journey in murky waters. Best to communicate a lot, strengthen your teams, and have total support of upper management.
Technical agile coaching usefully describes the work I do. Agile coaching helps your business to become more successful, often improving the way you plan and deliver software.
Technical agile coaching focuses on how people design products, write code, and deliver high-quality products.
My aim is the same as other agile coaches. I improve the agility of the organizations I work with. I use coaching, mentoring, teaching, and facilitation techniques just as other coaches do.
My main focus is how the source code is written, the design defined, and the architecture formulated.
Our goal is to deliver a highly successful product.
Agile Approach
My own interpretation of agile as doctrine is:
-
Reduce the distance between problems and problem-solvers.
-
Practice Gemba.
-
Take small steps, collect data, validate every step, update your approach. Apply the Plan-Do-Check-Act PDCA loop. Clean up as you go.
-
Lead and cycle-time are measures of organizational agility. Track them.
Do not ask for permission when you want to continuously improve. A professional is supposed to improve. This is a core responsibility of your teams and team members.
You have the retrospectives to identify and plan your improvements. You must allocate time for implementing the improvement in every sprint. Scrum is clear, at least one improvement measure is a high-priority backlog item in the next sprint [1].
If you can choose, do not use SAFe. I observe organizations struggling with SAFe’s over-standardized, phase-gated processes. The top-down control generates waste in the value stream and discourages engineering talent creativity. It seriously limits autonomy and experimentation in the teams. It can promote silos in the organization, preventing platforms from becoming real business capabilities enablers.
|
Thoughtworks put SAFe on hold in their Technology Radar Volume 24 released in April 2021. On hols means proceeding with caution. Said bluntly, just do not use it if you can choose. |
Ways of working
The following three levels of coaching are commonly necessary:
Organizational LeSS Coaching
A coach works with multiple teams and the management to improve the organization and its structure. A clear vision of how LeSS organization could be:
-
Organizational structure and design,
-
LeSS,
-
Role of management,
-
Adoption and goals setting,
-
Managing an organizational improvement backlog,
-
Changing management practices from controlling day-to-day work to building capability,
-
Managing work: product backlogs and how the organization manages them,
-
Dealing with interruptions,
-
Human Resource practices such as appraisals and career paths,
-
Facilitating organizational release/roadmap planning and retrospectives.
Team LeSS Coaching
A coach works with at most a few teams to improve their team-working and LeSS practices. It is common for a coach to take on the Scrum Master role. A team coach typically focuses on:
-
Team responsibilities with self-managing teams.
-
Facilitation.
-
Improving the team’s decision-making and conflict resolution.
-
Transparency in the team.
-
Making organizational impediments visible.
-
Improving the relationship between the Development Team and the Product Owner.
-
Product Ownership (of both the team, the PO, and other stakeholders).
-
Role and contribution of the team’s management.
-
Improve Scrum practices (and technical practices).
-
Educate and coach the team’s (future) Scrum Master.
Technical Practices Coaching
A coach works with (or on) a team on their actual codebase to improve the technical practices and adopt agile development techniques.
A technical coach is an expert on software development techniques
LeSS strongly emphasizes technical agility and promotes associated good practices. High-quality products require well-trained professional developers and mastery.
Examples are simple design, refactoring, unit testing, test-driven development and acceptance test-driven development.
A coach typically focuses on:
-
Discovering “code/design smells”.
-
Places where code/design could be improved.
-
Explaining modern, “clean” code that is legible and easier to change and maintain.
-
Refactoring “smells” into clean code.
-
Writing unit tests.
-
Test-driven development.
-
Test automation with continuous integration and continuous delivery.
-
Specification by Example (Acceptance Test-Driven Development).
-
Efficient and effective working practices (IDE, automation).
-
Applying design patterns.
In all our mandates, one major activity is improving the legacy code.
Legacy code is Code without tests
Legacy code is Profitable code that we feel afraid to change.
How Much Coaching?
The most successful LeSS adoptions we have seen had the following structure:
One internal and one external coach
This pair provides the overview of the LeSS adoption. They together coach management. They are also involved with team and technical coaching.
External team coaches who help the teams become better and focus on training the Scrum Masters.
External technical coaches who focus on training internal technical coaches.
Have some technical coaches work with the teams, but let them focus on training internal coaches. After that, reduce, not eliminate! the external technical coaching or let the external coach move to a new area.
Be Patient, The Time Horizon is Years
-
Trust your people.
-
Create opportunities.
-
Establish a learning culture.
-
Thrive for craftsmanship.
-
Let the team use internal social pressure.
-
Eliminate specialization, push mastery.
-
In the beginning, follow the LeSS rules.
-
Extended responsibility, rounded products provide room and freedom for better decisions.
Remember
LeSS is Scrum, it is Large Scaled Scrum Feature teams are economical. Cross-functional Technical excellence is the essence of a quality solution. One product owner for the whole product provides focus.
The product owner is where the money is. Depending on your organization, put him where the budget comes from.
Move from a component owner to become a component mentor. He is responsible for teaching others how to adapt and evolve the component.
References
1. Sadly, the Scrum Guide revision of 2020 removed this rule. They deleted this PDCA mechanism.