Interview: Kelvin Soen On Waterfall, Agile & Scrum

The following is an interview between Kelvin Soen and myself.

Hi Kelvin, thanks for taking the time to run this interview. We both spoke at the very first agile Indonesia conference in 2016 and you’ve been a very enthusiastic member of our scrum community. In your role, you have moved your development teams to scrum and you seem to be deeply into agile. Let’s start with a short introduction about yourself (your role, how long you’ve been working with agile and the current company, etc)?

My role is head of software development. I have been working with the current company for approximately a year. I have been implementing agile since my previous experience for approximately 3 years ongoing.

You have been a ‘project manager’ and now you are more into scrum. What would you say are some big differences between traditional project management and the way scrum proposes us to work?

Basically, the difference is the deadline. In traditional PM we focus on deadline and scope while leveraging on the other variant: resources. In agile, we focus more on deliverable and quality while we put aside other aspects as a variable (timeline and resources).

Most people know the golden triangle of project management which you refer to here. When we google ‘waterfall versus agile’, a lot of different versions of that model come up. I found this one for example:

In this model, quality is the variable in the middle. And they used features instead of resources. How do you see quality and features at play in the two different frameworks?

In my terminology, resources mean costs and features mean scope. Quality and features have similar traits in both framework; high quality and many features will require maximum time, vice versa. The only difference is: in agile quality is a MUST while in waterfall it is dispensable. And to achieve this quality, time and cost are required, leaving features to be ranked in prioritization (variable).

Another thing that often comes up is that deadlines are still imposed by management or customers. So even though we use agile, some management teams hold on to deadlines (which also seems reasonable as products need to be launched). In your experience, in projects that have deadlines, what’s the difference between waterfall and agile work?

I think that the fact deadlines fall almost 90% of the time is the catalyst to the birth of agile. In waterfall, a deadline is imposed at the beginning of the project when team and stakeholders have completely no idea in mind about the skills of the team, tasks required or design flaws. This is a perfect recipe to fail the deadline in the first place. While in agile, we iterate work every certain week to re-estimate or re-arrange deadline based on facts found in the field. It makes it more reasonable to come up with features estimations based on how much a team can deliver within a specific period of time.

One thing I notice is that managers who still impose waterfall based deadlines, while disregarding the facts, will only exhaust themselves with deadlines to finally succumb to the team’s velocity (agile). This is still the mindset of the majority of managers (especially non-technical) though, who still think that deadlines will boost and propel their business to the next level related to product delivery.

Another thing I found is that sometimes it is better to let them struggle with deadlines and then present facts and data of a previous delivery to show what agile might offer than to contradict them in the first place. As the saying goes: only a child who is already exposed to the damaging pain of a frying pan (waterfall deadline) will avoid making contact with it (switch to agile instead).

You’ve transformed your development teams. What do you see as the 3 most important things in the role of an engineering head or software department head in moving people to scrum?

  1. Empower/coach team
  2. Paradigm change from top-down to bottom-up
  3. Focus more on the environment; provide metrics for the development of each function, ensure every team members have a chance to speak out, establish innovative workplace.

Number one is a very interesting point in the Indonesian context. Many people are used to hierarchy. Bosses like to ‘give orders’ and employees like to ‘get orders’. Without orders, some people are confused and don’t know what to do. How do you go about ‘teaching’ your team to be self organized, to take responsibility?

This is a challenge and I am still learning myself. This is extremely hard for a team that has no person with leadership potential in it. But it is the first thing to identify in a team to make itself organized. A good thing is if you are handed a team that already has proper leadership escalation. But there are cases when you are handed a team of leaderless ‘lost chicks’. If you, yourself, have the technical capability you can actually lead the team yourself. Otherwise, if there is a more technical capable person in the team (as is mostly the case for a Scrum Master), you need to coach the person to be in charge and most importantly feel engaged with the team.

By coaching, I mean basics supervisory skills like coordinating, delegating tasks, etc. Agile best practices like daily meetup, refinement, retrospective, etc to agile technical aspects like continuous delivery, continuous integration, DevOps and so forth. Once the team can make a decision to apply or experiment with a tool, technology or methodology AND be responsible for the outcome, the team is one step ahead in becoming self-organized. Even though you have a concern or disagree, it is better to let them see the results themselves and learn from it. This, of course, excludes common sense mistakes such as agreeing not to utilize automatic deployment in which case you should intervene and justify.

Can you elaborate a bit on the paradigm change you mention? Why is that important? And how have you enabled your organization to become more bottom-up?

I think it is super important nowadays as this is the culture of the so called Silicon Valley. Bottom up paradigm bestows each employee with entrepreneurial and problem-solving opportunity, instead of regarding them only as a muted machine designed to get things done. Creativity and innovative ideas are prized more in this type of organization which allows the organization to be innovative and disruptive.

Your third point covers many aspects. What do you mean by environment? What kind of metrics do you use?

A good environment is when management can have a clear transparent helicopter view of the organization. That means they can see clearly in which process, teams or procedures the organization stumbles or lacks. In software development, for example, you have front end developers, back end developers, quality assurance engineers, business analysts, designers and so forth. The kind of metric I mentioned above should be able to pinpoint which areas go wrong and which areas work well, very specific to each individual if possible. It will provide the management with the tool to make strategic decisions to propel the business even further.

How did you get started with scrum?


Ok, so you went about reading the scrum guide and articles online? And then what were some of the first ‘steps’ you took to implement scrum in your organization? Many people find it challenging how and where to get started, so it’s good to hear some practical experience on that.

In my case, I just implement it right away. In startup world agile, especially scrum is accepted as the general way to do things. So I never have difficulty persuading management or transforming a waterfall culture. Of course, you will have some failures or things that you feel are not suitable for your organization. And that’s where the agile community or forum can support you, to share issues or ideas worth implementing in your business.

What roles did you transform into the scrum roles?

Project manager, management and stakeholders

Ok, and what role became scrum master? What role became product owner?

I personally become the scrum master. The management (CEO) takes part as the product owner. Once the organization has grown large enough, it can have specific product owners to allow the management to focus on other areas.

What were some of the challenges you faced in moving the teams towards scrum?

Adapt to each team and organization characteristics. Each team and organization have a unique approach, mindset and difficulties in implementing agile.

So what you are saying is that there is no ‘one size fits all’ way of implementing agile. Do you have some more specific examples of challenges you have recently faced?

For example, in one team we do not need an analytical phase, moreover a specific team of system analysts. But in a different product which is more complex in term of technical design and model relations, we required this specific team before development begins.

If you compare the way things worked in your company 1-2 years back and the way they work now, what are some of the biggest improvements (can be outside scrum….)?

I don’t exactly change from traditional to agile. It was more like I moved from a traditionally structured company to a more agile one, including forming an agile team from scratch. From the experience, I can tell that agile is the most suitable framework (not only in software development) for your organization to survive in this fast paced and ever changing world. The methodology encourages and induces innovation through which the organization can survive and thrive.

What have you done to make your teams stable?

Restructure the team, re-organize procedures, persuade and set expectations of management, implement lean startup methodology. And most importantly: review, review and review. Adapt to find the most suitable approach. Base them on accurate data, though, otherwise, too many changes only cause confusion and waste of time.

How did you combine lean startup with scrum? With the review, I assume you mean doing retrospectives on the team level or do you mean something else? It would be interesting to hear some of the data you have used to base your decisions on.

I do retrospectives to get insights internally. Lean startup requires you also to gather insight every certain period externally. We can do this by AB testing, surveys, etc and implement the results of the product. I’m afraid those data are classified for now

Sign In or Register to comment.