Be More Agile with LeSS, Part 4: Agility Requires “Respect for People”
The importance of cultivating trust in practicing the agile way of working.
In this multi-part blog series, I will share useful lessons learned from the Large-Scale Scrum book and the four-days Certified LeSS Practitioner training. Now with more ground-level stories of LeSS adoption in DKatalis. As examples will help readers learn new concepts easily.
- Part 1: Why Agile?
- Part 2: What is LeSS?
- Part 3: Why LeSS? Why Not Others?
- Part 4: Agility Requires ‘Respect for People’ (this post)
- Part 5 (final): Lean Thinking
There are a lot of complaints about agile approaches. Google it by yourself.
And it’s pretty expected. With Scrum — the most popular agile approach — and its tangible artifacts, roles, and events, onboarding people to ‘do agile’ is relatively easy. Now, combine that with the promise of increased productivity, and boom! You have a Scrum/Agile hype.
Based on my observation of Indonesia's agile communities since 2013, I saw some ‘aha’ moments in the early phase of the adoption. After that, the results were varied. Some were good, some were so-so, and some did it wrong (like in the Hacker News post below), then they rolled back to the previous way of working.
The Importance of Principles
I’m going to make a case:
Principles / values will help you see beyond the rules and mechanics. It explains the WHY, gives nuances, and in general, eases the implementation of the rules itself. Without those, there’s a big chance that you’ll get bad result.
To support that case, I’ll elaborate on the principle that I felt most throughout the year of LeSS adoption in DKatalis. Hopefully, it’ll explain why the absence of principles will lead to a dysfunction of agile adoption.
Respect for People
I’ll elaborate on some of my observations on the “Respect for People” principle in DKatalis, and conclude each of the observations with its relation to agility.
1. The containers for people’s feelings and self-agency
At work, many things can disappoint us. The question is:
- Can you express it & initiate some changes to deal with it?
- Or, you often just wish your boss (or others in general) would come and remove your blocker while you numb yourself from the pain by gossiping about it?
The former gives more respect for people, compared to the latter. It respects people’s feelings and their self-agency in initiating the fix to their own problems.
After adopting LeSS, we have a place for anyone to express their disappointment & discuss what’s next. And it can reach the upper management through these ways:
- Whenever someone has a concern (e.g. suddenly dragged into a meeting without enough context), he/she is encouraged to raise that in the bi-weekly team retrospective. There, he/she can gauge whether it’s a valid concern or not.
- If the team can’t solve the issue, they will bring it up to the overall retrospective (scheduled shortly after the team retrospective). There, the concern will be discussed with a representative of every team from the same area (4–8 teams who work closely).
- Suppose the area still couldn’t address it. In that case, they’d appoint someone to arrange a cross-area retrospective meeting (specifically to discuss that issue), or they can bring it up in an open forum (a weekly optional alignment session with upper management & various department leaders invited).
Without these kind of containers, there’s no place for people to find problems in his own way of working, to solve them, and to make improvements. The organization will be less agile.
2. The ongoing cultivation of trust
It’s easy to raise a non-personal concern (e.g. slow laptop). What if your concern is caused by your teammate’s behavior (e.g. often in slow response)? Imagine you’re in a team retrospective session. Would you dare to share your negative feelings in front of the person without fearing the repercussions?
For me, the answer is “yes if, and only if, I trust my teammates that they’ll be open to hearing my feedback”. The retrospectives and open forums above will only be a boring, awkward meeting if the participants are too afraid to share their worries, disappointments, or even anger.
Then, the next question is ‘How?’ Trust can’t be built fast and straightforward like we build a building. It’s a long journey, touching various aspects. It’s more akin to gardening, trust is something to cultivate.
There are a lot of ways to cultivate trust in teams. Here are some of the examples I saw:
- Self-designing team workshop
How does an organization re-create team structure? Usually, by leaving that task to the manager of the teams. What if we let the teams design their own team structure? That’s what exactly happened in DKatalis. The product development people arrange themselves into a team of 5–7 members each. This way, people get to decide who their teammates will be (obviously, with some constraints in place). Also, because it's their own choice, there is less barrier to cultivating trust within the team moving forward.
- Offline weeks
DKatalis doesn’t have an X-days-WFO-per-week policy, and we primarily work remotely. After some ongoing discussion between team reps & tech hubs, we found the benefits in flying the teams who work quite closely (around 4–8 teams) to Jakarta HQ for a 2-week WFO. This fully funded, every couple of months, in-person session is an investment to cultivate more trust. Not to mention the funded outing called DKaboodle! It’s worth the money since in-person experiences help a lot in cultivating trust. - Agile coach observing team & area
In each area, there must be at least one agile coach. They must earn the trust of the teams in that area to detect unspoken negative sentiments within or among the team effectively. Hopefully, the trust level would never fall below a certain level. If you wonder what I do if I notice some unspoken negative sentiments, that will be another story for another day. So, stay tuned!
Without enough trust, both the retrospectives and the teams won’t be functioning optimally. They’ll be less open and more passive. Relying more on their manager, their agility will be decreased.
3. Respect for the developer’s estimation
Not even once in my entire year here I saw the Product Owner seriously disrespect developers' estimation of how long they can finish a feature. (e.g. “Come on, I know you can finish it earlier” or “Your team can take more items for this sprint, I suppose”).
Well, to be more transparent, one product team member sometimes does it. We know he’s only joking, and we love it, as he’s our favorite trusted class clown. Shout out to the one and only:
If you don’t respect the team’s estimation, it implies that they’re not professional enough. They’ll buffer a lot — anticipating your negotiation. It will become more a contract game, rather than collaboration in solving customer’s problem. Thus, less agility.
Why Respect for People?
Money
Agility — or adaptability — according to its own definition, requires a lot of self-awareness and self-agency from everyone. With fewer of those, it’d be harder to move, fix, and align accordingly. The organization will be stiffer and less adaptive. That will increase the risk of bankruptcy due to being outsmarted by a new small startup. We’re in the business of innovation race anyway.
Every entrepreneurial innovator wants money. However, agility/adaptability is not for everyone.
If you believe that people basically have little ambition, avoid responsibility, and are individual-goal oriented (theory X), then pursuing agility is a waste of time and energy. If you see people as self-motivated problem solvers at their core (theory Y), then an agile way of working might benefit you. Theory Y respects people more than Theory X.
Back Again to The Importance of Principles
I’ve been attending many agile trainings since 2013. Yet, the Certified LeSS Practitioner training has a special place in my heart.
There are a lot of discussions and elaborations on deep stuff like Theory X & Theory Y above. The tangible artefacts, roles, and events are still there, but explained sufficiently.
LeSS puts a strong emphasis on principles / basic assumptions. It might be the reason why LeSS is less popular compared to other agile approaches. After all, we humans tend to walk on the easiest path in a short-term perspective, not a long-term one.
Next: more LeSS principles.
Are you keen to learn more about the agile way of working with Large-Scale Scrum (LeSS) framework? We’ve got you covered here!
