Be More Agile with LeSS, Part 1: Why Agile?

How it can help you lessen work problems and boost your team productivity.

Disclaimer: 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.

• Part 1: Why Agile? (this post)
• Part 2: What is LeSS?
• Part 3: Why LeSS? Why Not Others?
• Part 4: Agility Requires ‘Respect for People’
• Part 5 (final): Lean Thinking

When I wrote this, one of the DKatalis clans had kickstarted LeSS adoption and the rest will follow soon. LeSS itself is one of the Agile approaches in designing organization, collaborating with teammates, and engaging the stakeholders.

What is Agile?

(Skip this part to immediately understand what’s in it for you.)

Nowadays, these Agile approaches are already popular and infiltrate various aspects of the business (e.g. agile marketing, business agility, etc.). But do you know how it became so revolutionary and widespread? Let’s take a short peek at its birthplace: the software industry.

Since its rise in the 60s till the late 90s, almost every software was built the way a bridge is built:

No wonder, this serialized step approach is often nicknamed “waterfall”. However, in the 90s, some visionaries discovered that — in the context of software development — this waterfall approach was already doing more harm than good.

It’s because unlike a bridge or a skyscraper, what we want to build (backlog) in software consists mostly of unvalidated assumptions. The business value of most parts of a bridge and a skyscraper has been validated from the start.

A bridge or a skyscraper construction is, essentially, a duplication project.

A software? Not a chance. We will waste money if we only precisely copy-pasting competitors. Unfortunately, we can’t also just listen to the customers and build anything they’ve requested. Most of the time, customers don’t even know what they need. So in the end, we must keep imagining new features. And imagination requires some assumptions. That’s how assumption becomes an integral part of software development.

Designing a complete solution — full of unvalidated assumptions here and there — and delivering it to the customer at the same time, is a recipe for disaster. And that’s exactly what we’ll do if we implement a waterfall approach to develop software. Delayed project deliveries, a plethora of bugs, and unused features were the norm of waterfall software development.

The better approach is validating the best assumption in our hands, one at a time — just like what our high school teacher taught us in a science class. Usually, after we release a feature to the customers, reality will slap our faces. The users are abandoning our newest feature. Our number one well-calculated assumption was wrong. And we need to adjust the plan (or you can also call it a “set of assumptions”). Roadmap, estimations, and milestones keep re-adjusted. In consequence, teams and stakeholders need to communicate way more often than in the waterfall approach. Uncertainty is our daily breakfast.

Just like marketing, or business in general, building software is a never-ending experimentation, not a duplication project. Thus, they need a more agile approach.

Enough with the context, your time is precious.

Why Agile? What’s In It For Me?

So let’s address the elephant in this post:

“What’s in it for me? Will Agile reduce my work-related frustrations? Will it make me feel , at least , a little bit more excited, whenever I start my work in the morning?” ~🐘

The answer could be ‘yes’ or ‘no’, depending on your current condition. If you don’t have any frustration and are always excited to face Monday, then Agile will do little for you. However, if you often catch the Monday Blues regardless of how well your weekend went, Agile may be able to help. Even when your work hasn’t any relation at all with software development.

Before we get into how, let’s first identify any work-related frustrations you may have. I cluster them into three:

1. Lack of Purpose

Your boss frequently asked you to do things for which you had no idea why. Your work is supposed to solve customers’ problems and bring some money for stakeholders. But, you often wonder, “Who precisely are the customers and stakeholders? What kind of problem to be exact?”

Even when the problems are crystal clear, sometimes you doubt the tasks on your plate are the best solution to solve them. You consider them merely as temporary solutions that don’t touch the roots. Yet, you choose to swallow that doubt.

Your boss, just like his/her boss and the stakeholders, rarely triggers the discussion about the value of your work. There’s also no attempt to validate whether the current services have successfully satisfied the customers. It’s about shooting in the dark, and the political game of decision-making. It’s frustrating, especially when your colleague told you, “It’s all good man, as long as we all get paid”. You eventually came to accept this kind of unclarity.

2. Misalignment

There’s a lot of miscommunication about the details of your task; You and your boss frequently have different assessments of the outcome or performance.

Nearing the end of a project, the stakeholders suddenly complained about problems they should’ve reported 3 months earlier.

Your so-called partner doesn’t give any status updates, so all you can do is pray that they will deliver their promise on time.

One of your teammates delivered crap and looked down on others. Unfortunately, no one in your team, including you and your boss, is brave enough to call them out.

3. Micromanagement.

You often experience burnout.

You care about the quality of your work, but your boss and colleagues never care enough to listen to your ideas about it. There are no clear boundaries or expectations, so you don’t know which part might need improvements. In their ears, your estimation often becomes a deadline commitment. You feel like a cog in a machine that exists to only take orders and deliver.

When you get a promotion and have your own staff, you get really anxious about whether they can deliver or not.

So, can you relate to any of the problems above? Even more, is it so persistent that you have normalized it by now, just like Jakarta’s traffic?

If the answer is ‘yes’, then you are in the right place. Your life might be getting easier soon. :)

How Agile Will Minimize Your Works Problems

As you might have guessed already early in this article, basically, all Agile approaches (which LeSS is just one of them) share this basic skeleton:

1. Meet the customers and stakeholders often.
2. Visualize any works, plans, estimations, and agreements.
3. Let the team take shared responsibility.
4. Deliver frequently to the customers, learn how satisfied they are, and keep adjusting the plan to maximize future customer satisfaction.

Now, let’s connect those four approaches to the aforementioned work problems:

• Closer customers and frequent value validation will give a sense of purpose.
• Engaged stakeholders (along with a transparent plan, estimation, and value discovery) will boost alignment and a sense of trust.
• Trust will reduce delivery anxiety and micromanagement.
• Taking responsibility as a team will increase a sense of autonomy. Sooner or later, this autonomy (combined with a customer-focus setting and engaged stakeholders) will increase the team’s productivity and estimation accuracy. A simple recipe for happier stakeholders.

The Price We Need to Pay

Unfortunately, LeSS (as any other Agile approach) is not a plug-and-play solution. Habits changes are also mandatory. As this post mentioned earlier, Agile requires the teams and stakeholders to communicate more compared to the waterfall approach. And that’s not the only prerequisite.

Delivering a well-tested integrated product as a dozen teams needs a certain level of technical mastery. The ongoing transparency of work status, agreements, and estimations requires efforts and shedding some of our egos. It’s hard to share responsibility collectively if we don’t trust every member of the team, and cultivating trust also requires some work. Last but not least, LeSS wouldn’t ever work if we don’t know how (or even more, don’t want) to talk to customers effectively.

Should we abandon LeSS knowing those heavy prerequisites above? No. In fact, LeSS will help you cultivate those necessary new habits and mindsets mentioned above. Any habit requires a trigger. LeSS (or any other Agile approach) could provide a lot of new triggers. This is just a disclaimer that you won’t see the big result immediately; Even more, adopting the whole LeSS wouldn’t happen in a single day. We can adopt it brick by brick, and feel the small positive feedback in every brick we put.

This is just a disclaimer that you won’t see the big result immediately.

With this strategic position of LeSS in lessening your work problems (pun intended), it’s always good to know LeSS a bit more. You also need to know why LeSS is a good choice compared to other scaled Agile approaches out there. We will discuss those further in the next two posts. See you there!

If you’re a Katalis and interested in Agile but not working close to product development, LeSS might be too much for you. But don’t worry, feel free to contact Shirley Rompis, Rizki Yogaswara, or Ricky Saif to discuss several other options. Your work might be even closer to constructing a bridge than coding software, but many tactical practices in Agile approaches might still be beneficial to adopt. You still can increase your agility, even if you work on duplication projects.

Do you enjoy working in an agile environment with effective workflow and less friction? Then, you’re already a Katalis at heart! Join us 🤙