Interview: Artanto Ishaam, HappyFresh On Agile Processes And Building The Product Team
The following is an interview between Artanto Ishaam and myself.
Hi Pepe, thanks for taking the time to run this interview. We did the January meetup at HappyFresh and I got so many ideas and energy from that session that I thought it would be great to have an interview. What I noticed is that HappyFresh has grown beyond scrum only. I think it’s interesting to look at how you got there and share experiences others can use. Let’s start with a short introduction about yourself (your role, how long you’ve been working with agile and the current company, etc)?
Hello, my name is Artanto, but people usually call me Pepe. Currently being a Scrum Master in HappyFresh. HappyFresh is an online groceries delivery platform that offers a top shopping experience, so it’s an even better experience than your usual shopping activity. I joined 2 years ago with only one team that was already running Scrum but not in full Scrum. Some rituals were skipped and some processes weren’t defined yet. Right now, we’re working with 5 teams, the size is almost 4 times the size when I joined. Now we run with full Scrum and processes have been defined.
Thanks for the intro, sounds like an interesting period of growth for both you and the company.
A few weeks back, we did an Agile Indonesia meetup in your office. In the presentation, Joe showed an image of your scrum process. In that, I noticed that lean startup is ‘a natural part’. How do you guys combine lean startup with scrum?
We’re using lean principles: build – measure – learn as a foundation of our product iteration. We’ve got 2 types of sprints working in parallel for discovery purpose and development purpose.
Both have different goals.
- Discovery sprint
- Goal of the discovery sprint is to validate every single thing that we build is according to the goal we want to achieve. So, it basically comes from our organization goal that has been derived into our product roadmap.
- From the roadmap, we break it down part by part, epic per epic so we can easily define the scope and build the experiment.
- Problem definition: we list all our assumption, hypothesis, outcomes that we want to achieve, benefits to the users, and KPIs to measure. This is the most important part since our product is built to solve people’s problems, isn’t it?.
- Problem validation: check primary data, secondary data, context, users scenario, and trend. Analytics data is the most important one so we always make sure our tracking is working and we put the right tracking.
- Workshop and sketching session: in this session Product Managers (PM) are working together with a UI/UX designer in developing a mockup or prototype. Sometimes Development Team (DT) also involves in this session if we need to add technical advice/insight.
- Review mockup & recruit: double check the mockup and invite some people into user testing. Inviting people is also tricky since we need to choose people that match the problem we want to solve. That’s why having people who have market research, R&D, to join our member is very beneficial since they’re usually working with sampling and have research methodology as a background.
- Prototype development: the combination of interface and flow. We use Marvel (https://marvelapp.com/) to bring the real experience of our app. So the user will be able to engage with the prototype. This is important because we want to grab the real user experience so we need to bring a “look alike” environment to the sample.
- User testing: time to test the prototype!
- Mockup – prototype – user testing is working in a cycle, we revamp and re-test again until we got enough results.
- Review the findings: this is the last checkpoint of the cycle before the product backlog is created and we enter our backlog grooming session.
- Development sprint
The goal of the development sprint is to build the increment. Nothing special in this since we’re using usual Scrum sprint. All artifacts, events and rules are according to the Scrum guide. (http://www.scrumguides.org/). The only difference is that we have a separate session in defining the technical implementation that we call backlog grooming (weekly). We use that since having the technical implementation break down inside the sprint planning really takes time and makes the planning very exhausting. It also gives an opportunity for the PM to re-discuss with stakeholders if the technical complexity doesn’t make sense and needs re-prioritization.
Definition of Done:
That’s an interesting process you’ve developed there. The first part of your process, the discovery, looks a lot like the design sprint from Google with some lean startup flavor added to it. I think that’s also a very important thing in agility: use what you believe is good from other people and tailor it to fit your own situation. We don’t need to run ‘textbook processes’; we want to achieve our business goals.
You also work with kanban. What are some pros and cons of kanban (versus scrum)?
In what situation would you recommend teams to use kanban instead of scrum?
There’s no pure kanban project in HappyFresh. Currently, we’re only using kanban practices in our sprints:
- Top – down approach when picking works, working on it until finished before moving into the next sprint backlog.
- There are swimlanes: backlog – development – testing – review by PM/designer – ready to deploy
I think the main difference between kanban and scrum is on the sprint and iteration. I don’t think there’s kanban vs scrum. I see it as a different approach. Kanban and scrum are complementary to each other. Kanban didn’t acknowledge a sprint, so it’s probably hard to estimate when the epic is ready to ship to production. Whereas in scrum, we acknowledge the sprint so based on complexity and velocity we’ve got a little insight estimation when the epic is ready to ship to production.
Kanban also has the following approach: once it’s ready it can be deployed to production as soon as possible. In this approach, I don’t think it can accommodate well mobile app projects since submission to PlayStore and AppStore is costly. Scrum with its sprint approach may be more suitable there. Even though there are some engineering practices like feature toggling that can make mobile apps also suitable for a kanban approach.
So, this is the nature of the platform itself: if the deployment is costly, which makes deployment as soon as possible hard, then maybe scrum is more suitable because you can combine all changes during the sprint and deploy to production by the end of the sprint. But on the other hand, you can use kanban to get your changes live to production as soon as possible. So, using scrum we cannot deploy the changes to production as soon as possible? no, you also can. That’s why I said this approach is actually complementary, we can combine them. The most important thing is: kanban didn’t acknowledge the rituals that scrum has, so in the name of product iteration scrum is complementary to kanban.
Yes, I concur with your ideas about Scrum and Kanban being complementary. The way I see it: it’s best to start with scrum because the framework gets enough ‘prescriptions’ for teams to know what to do. If you start from ‘agile mindset’ and let immature teams figure out how to ‘be agile’, it may be hard to get results. Scrum helps there. And once the teams get mature, they can start playing with Kanban or other agile frameworks.
I saw in your LinkedIn profile that you described your experience with several (agile) project tools. What’s your favorite tool and why? For what type of work/project would you use what tool (or otherwise: for what type of work would you use Asana, Trello, Basecamp or Jira?)
I would say Trello is the best and most simple one. Best because it is simple. Simple means to handle just one or two projects, it is okay. But if it turns into multiple projects that have a lot of complication inside, I would prefer JIRA. JIRA already has a backlog structure, sprint management, release management, a lot of charts that would help you. Even you can define different swimlanes, different workflows, different status, etc for different projects.
I only use Asana for personal tasks, because it only knows done or not done (to-do’s based), we cannot have swimlane in there (i know currently they’re adding a swimlane feature, but still I think it didn’t bring additional value toTrello).
Basecamp? We used it in our HappyLabs project back then. It’s to-do’s based, quite similar to Asana but in a more complicated way.
If you’re just starting to use a tool I would suggest Trello first. The con is you need to define backlog structure first because Trello gives you the flexibility to put everything inside the card. That’s why you need a standard. You need to also move all done backlog to a different board. So, every sprint means a new board or you can keep it on your current board but your board will look messy.
Next, if you need more suitable one, JIRA is perfect.
Let’s look at the engineering practices you use. How would you describe ‘continuous integration’ to your grandmother? And what’s the difference or relationship with DevOps and continuous delivery? Are you doing pair programming and if yes, what’s the benefits for your work?
DevOps is not a product, DevOps is a culture, practice or movement that emphasizes the collaboration and communication between other IT people (outside developers) and software developers. They’re collaborating in automating the process of software delivery and infrastructure changes. It creates an environment and culture where building, testing and releasing software can happen frequently, rapidly, and reliable.
DevOps & continuous delivery? Imagine there’s a machine that builds the service, and there’s a conveyor belt that rolls the services in a manufacturing production line. DevOps is the machine, while continuous delivery is the conveyor belt.
Continuous Delivery (CD) is an essential ingredient for teams doing iterative and incremental delivery. Continuous delivery is an approach where teams can make sure that every change to the product can be released, and that any version can be released in one click. CD’s goal is to make releases dull and reliable, so organizations can deliver frequently, at less risk and get feedback faster from the customer until deployment becomes an important part of the business process and competitiveness of the product.
Pair programming? Yes, we do. The biggest advantage is, of course, knowledge sharing. Let’s say one of the team members is sick or on leave, the works can be continued by the other one. Other than that, one can be reviewed by the other one so we can make sure code convention, code style, quality code, is easier to maintain. The non-related work advantage is to give a team member a friend to discuss when there are any difficulties in the work itself.
Ok, if my grandmother was still alive, I guess she’d get the big picture there 🙂
Final question: Would you describe yourself as an agile coach or a scrum master and what are the main differences in your perspective?
I don’t think there’s a difference between agile coach and scrum master. Scrum master must ensure every single member is following the scrum core values (of course also scrum mechanics) while the scrum core values use agile as a DNA. So as a scrum master you also need to inject the agile DNA into your team. It’s similar with agile coaching, isn’t it? The main difference is maybe that an agile coach can use any other framework other than scrum, while the scrum master is a special role that is included in the scrum framework. Other than that, coaching about workflow, engineering practices, etc is included in both responsibilities.
So, agile coach or scrum master doesn’t matter for me, I prefer to be called ‘friend’ by my team.
Yes, the roles overlap a lot. I think in most cases, an agile coach is a person with a lot of experience running agile teams. The coach usually coaches multiple teams and can work at different levels through the organization, not only coaching teams but also leaders and managers.
OK, friend, thanks for sharing your insights! I especially liked the scrum-lean startup process you shared and I think revealing such models to the Agile community is good. Others can learn from this and (try to) apply it. Speak to you soon, terima kasih.