Herding the Stray Sheep: Lessons for Shepherds

About this Publication

In an organization, a single introduction to an agile way of working is not enough to make teams consistently adopt agile practices. Without maintenance of agility, teams revert back to their initial non-agile ways of working. Agile Coaches are required to “herd the stray sheep” by enabling teams to find their way back to agile practices. This paper follows the journey of a team that had strayed but later found their way back by leveraging the team’s willingness to change, receiving regular feedback from outside of the team, and participating in an agile community of practice.


This is a story of a farm, sheep, and a shepherd.


Once upon a time, there lived a family in a beautiful farm in a meadow. On that farm was a flock of sheep and every day they would go to and from the grassland by the river. As time went on, the family farm wanted to expand and so the owners of the farm brought more sheep to the flock.

The more sheep came, the more difficult it became to herd the sheep. Some even went astray. Because of this, the eldest daughter was given a job. She was to be a shepherd. However, she could only take care of a handful at a time, some still strayed. She wondered, how she could herd all those sheep?

One day, the shepherd girl found a lone dirty sheep walking towards the farm from the river. It was the one that had strayed! The shepherd then retraced the journey of the returned sheep; with this newfound knowledge, she hoped to be able to herd the stray sheep from a distance.

Replace the farm with a billion-dollar company, the sheep with product development teams, and the shepherd with Agile Coaches. In this story, we will follow the journey of a stray team and how they found their way back to agility.


There was a farm in a meadow where sheep grazed happily.


Bukalapak, which means “to open a stall” in Indonesian, is a billion-dollar e-commerce company in Indonesia. Founded in 2010, the small startup grew to be one of the leading online marketplaces in Indonesia, where anyone can buy and sell various products. Its mission is to empower small and medium local enterprises.

To better achieve its mission, Bukalapak underwent a massive growth between 2016-2018. This included the creation of development teams consisting of small cross-functional product teams of software engineers, data scientists, software quality analysts, user experience researchers/designers, and product managers. Back in 2016 there were only 6 teams, today in 2019 there are more than 60.

2.1        Opening a path to the grassland

The sheep went back and forth to the grassland every day. To help the sheep, the farm owner built a passage and put up a fencing along the path.


Prior to 2016, there was no agreed-upon development methodology and teams were free to define their own. “Chaos” would be the right word to describe the result. Teams lost focus; there was no task prioritization and they did not know their capacity. Consequently, they often bit off more than they could chew. Team members were micromanaged and developed features without knowing their impact. Triggered by an underperforming team, the Vice President of Engineering introduced agile practices to teams. Between June to August 2016, he coached five teams on Scrum practices (e.g. two week long sprints, retrospectives), agile estimation (the concept of story points, using poker planning to estimate stories), and agile planning (the concept of velocity and how to derive a release schedule). In addition to that, he also introduced a new tool (Atlassian Jira) to the team, which provided transparency.

The impact of the coaching was great: teams could better prioritize tasks, everyone knew the goal of every sprint, processes became clearer, story detailing was better, and release dates were more predictable. A new way of working was born and by August it was adopted by seven teams in Bukalapak. At this point, all the teams had adopted the good practices as taught by the VP of Engineering. Afterwards, teams were left to experiment on their own. The teams were free to adopt more good practices and were encouraged to share it with other teams.

2.2        From a humble farm to a farming enterprise: problems start to appear

The business was growing and the farm had more sheep. Over time, it became more difficult to herd the sheep.


During 2016-2018, Bukalapak scaled up massively. While the original seven teams understood how to organize a product development process, newer teams did not. In addition, teams that had previously practiced agile reverted back to non-agile practices (“straying”), which were also copied by new teams. For example, the Product Managers (PM) made promises on feature delivery dates without consulting first with the engineers, story estimation was not done by the development team, or the retrospective was not really a retrospective.

What do we mean by “not really a retrospective”? When we joined Bukalapak (early 2018) there were only 20 teams. We would occasionally join teams’ retrospectives. In those meetings, we saw teams quite randomly express what happened or what they felt during the previous sprint. Team members would often say things like, “Oh, the weather was nice the previous sprint,” or, “Yay, since this is January, we get a pay raise this month!” They were not actually discussing what worked and what didn’t work during the sprint. At most, they might say, “Yay, we completed this feature” without discussing what made them deliver on time or, “Oh no! That feature was still buggy and we could not release it yet. What should we do next? Well, I guess let’s just fix the bugs…” without discussing what actually caused the bugs.

At the time, we ourselves were rookies in agile and did not fully understand the concept of retrospectives yet, so we accepted the meeting as it was; not asking a further question or giving feedback. What became clear to us over time is that retrospectives are not about discussing what happened, rather they are about discussing why things did or did not happen. That understanding is fundamental to having a successful retrospective.

A lot of teams were doing “mechanical” agile: they copied what others were doing without understanding why. New team members saw veteran ones poker planning without understanding the concept of story points; no one knew what velocity meant or how it helped determine the schedule of a feature release. Here, we could see that merely “practicing” agile did not mean that a team would be agile.

In order to be agile, practices have to mean something (otherwise, it would frustrate everyone quickly). When the new way of working was rolled out, the VP of Engineering did not have the capacity to ensure that everyone understood agile. Furthermore, he assumed that when new teams were formed, they would “automatically” adopt agile practices since it was the norm. Evidently, this was not the case and without someone to maintain the adoption of agile practices, non-agile practices started to creep in.

This led to problems. First, there was no well-known person (other than the VP of Engineering) whom anyone could ask about agile practices. Second, there was no one to make sure that teams had a good understanding of agile practices. To close the gap, an agile “guild” (community of practitioners) was initiated in November 2017. This agile guild met monthly and had a chat group discussing agile practices.

2.3        The shepherd’s challenge

The eldest daughter became a shepherd; she had never herded sheep before but she had to make sure all the sheep made it to the grassland everyday.


Fast forward to 2018. By now, Bukalapak had scaled up considerably. Along with the increased complexity of the organization, Agile Coaches were needed to maintain the agility of the organization by improving the product development process. Four new internal Agile Coaches were appointed from various backgrounds, from full-stack engineer to product manager. They were all internal recruits without prior experience on agile coaching.

This paper is written by two of Bukalapak’s Agile Coaches. We were tasked to maintain the productivity of a thousand people in more than 60 tech teams, grouped into 10 product themes, each of which we called a “tribe.” To make the most of our resources, we focused on coaching one tribe at a time despite seeing many questionable agile practices across the organization. Some questions emerged: How do we maintain good practices in teams that are not being coached at the moment? How do we help them find their own way into adopting good practices? We had no idea which teams were facing which problems.

To answer these questions, we identified a team that had gotten back on track and re-adopted agile practices after having reverted back to non-agile practices. As agile guild facilitators, we first met the team back in mid-2018 when we were facilitating an agile guild meetup. By that time, we were aware that three team members (Susi, Tono, and Ani) from the above-mentioned team were sent by their engineering manager who said: “You need to learn about agile practices.” One of the topics in the meetup was about story estimations. One of us explained, “In story estimation, teams use story points and poker planning. In poker planning, the team members need to estimate the story. Why? Because they are the ‘experts’. They have the technical skills and knowledge to do that. Moreover, the ‘discussion between experts’ that follows makes the estimates accurate.”

Ani was flabbergasted, “So THAT is how you do estimates?!” I asked her why she looked so surprised, and she humbly explained, “I am the Associate Product Manager of the team. All this time I was the one assigning story points! It seemed to be painful for the team, and now I think I understand why. Even though it is my responsibility, I did not have the knowledge and technical expertise needed to properly estimate the stories!” Subsequently, Susi explained that stories were frequently underestimated and the development team felt overworked for no good reason. A discussion took place and we helped them understand the principles behind story estimations. By late 2018, we were aware that they were doing well. They did not feel the pain anymore as they were responsible for their own estimates.

This is the story of the stray sheep found its way back to the herd; how a team, that once struggled with their way of working, was able to re-adopt agile practices. We identified how they addressed the pain points that rose from “questionable” agile practices. Subsequently, we used the lessons learned to find approaches to support the adoption of agile practices in the organization. Not only the ones we have not coached yet, but also to maintain agility in the teams we have coached. The story is told from our point of view‒the Agile Coaches: the shepherds who herd the stray sheep.


3.1        The journey of the stray sheep

Luckily, the shepherd girl found a dirty sheep walking towards the farm from the river. It was the one that strayed!


The team first started in 2016 and more people joined the team by mid-2017 when their product scope changed. Despite not being coached directly by the VP of Engineering, the original team adopted agile practices when they began. Over time, they freely adopted new practices. For example, by the end of 2017, the team added a code review process. They also changed their Kanban board columns to reflect this change, so that code review was now mandatory. The addition of this resulted in an improvement of the software quality.

In any given sprint, the team had two meetings other than the daily standup. The first one was at the beginning of every sprint, attended by all team members to conduct the retrospective, the sprint planning, and the story estimation session. The second one was the weekly sync. In this meeting, the PM or APM (Associate Product Manager) would start with showing the team their sprint burndown chart and then went through the tasks on the current sprint backlog to discuss if there was an issue. It was similar with the daily standup, but with a deeper discussion on the technical issues or impediments.

When the team first started, the development team estimated the duration of the work and converted it to “story points” without fully understanding what story points are. In early 2018, they no longer did the estimation because it was already done by the APM. It was her initiative, since the team did not understand story points. Imagine a development team being asked to estimate a user story, but instead of discussing, each of them picked a number and defended it with their own arguments without listening to others’ argument. Or they would “negotiate” the numbers in that they picked any number in between as an estimate. For example, Putra, a developer, chose 8 points for a particular story, while another developer, Putri, chose 3. Instead of explaining to each other the reasons behind the numbers, both Putra and Putri said: “Okay, let’s split the difference,” and they happily settled on 5 story points. These were common practices that often happened during the estimation session. At this point, no one in the team realized that later on this practice would set them back. So, they continued doing it until ultimately they suffered from the long duration of meetings, not enough detail on user stories, underestimated story points, and a big gap between committed and completed work per sprint. As a result, the team was exhausted, trying to complete never-ending work. By mid-2018, they were finally aware that they strayed.

If we take a step back and try to explore what made the team stray in the first place, we might discover that it stems from the culture of pragmatism in the team that was brought in by the PM (Product Manager). When the VP of Engineering established agile practices in the organization, he asked the PM to use those practices in his new team, while being sure that the practices would be adopted since the then new team consisted of engineers who had been coached before. Apparently, both sides failed to maintain the good practices due to different reasons. The PM was being pragmatic: he did not care about the team’s way of working as long as his product metrics were good. The original team members did not even understand the value of implementing agile practices.

There is a mechanism in Bukalapak where engineers have a regular one-on-one session with their Engineering Managers (EM). Here, they can channel their aspirations. Suffering from the strayed practices, Susi, Joko, and Tono, three engineers who later became “the agents of change,” separately came to their EM with this problem. They were advised by their EM to join the agile guild meetup so that they can learn how the other teams were doing with their practice and see if it was worth applying in their team.

Once they joined the meetup in July 2018, they quickly learned from other teams’ practices and realized how far strayed they were. But, this did not get them down. One of the team members, Susi, attended the guild meeting and was paying close attention. On the next retrospective, Susi pointed out to her team saying, “We are doing this totally wrong. This is not how agile practice is supposed to be done.” Of course, her statement was questioned by the other team members: “So, Susi, why don’t you tell us how it is supposed to be done?” She then explained to them what she recently learned from the agile guild. Some of them didn’t look interested, but most of them were sincerely open to learning this kind of practice and improving the way they worked. With this new agreement, the team conducted a special meeting which resulted in rearranging the schedule on agile practice. Subsequently, there were no more long tiring all-in-one meetings at the beginning of each sprint. Rather, there were 4 short separate sessions (story detailing/grooming, story estimation, retrospective, and sprint planning).

They started to use planning poker on story point estimations. Although during the first few sprints there were still misestimations here and there due to lack of story point calibration, they got better over time. Not only making the meetings more focused, but this change also led to better iteration planning and better detailing on user stories.

A few months after this team’s transformation, we conducted an initiative called “Scrum Master Bootcamp” where we taught the engineers the basics of scrum and how we practice agile in Bukalapak. We trained them in facilitating their own scrum events since there was no specific role in the team whose job was to maintain the scrum practices. After the bootcamp, every team has a Scrum Master who facilitates the scrum process. Little did we know how much this initiative helped this team during their transformation. Tono even highlighted the importance of having a Scrum Master in his team, saying, “Our Scrum Master has always been there for us. Not only facilitating, but he also taught us everything he learned from the Bootcamp so that we shared knowledge about the practices and did not repeat the same mistake twice.”

3.2        Finding a way back to the flock

By retracing the journey of the returned sheep, the shepherd- hoped to be able to herd the stray sheep from a distance.

3.2.1    The agents of change

In this team, three engineers pioneered the team-wide change. Despite only having joined the team later and not coached in agile practices, they had courage to raise their pain points and went out of their way to find a solution. This action brought the team “back to the flock.”

Two of them (Susi and Joko) previously joined other teams in Bukalapak, which made them able to compare the current team’s development process with the previous teams. Meanwhile, Tono was a newcomer who had no prior experience in product development. However, all three felt uncomfortable doing the team’s practices, which turned out to be non-agile.

Susi, who was the engineering lead, was known as the most vocal among her team members. She not only criticized the non-agile practices but actually proposed solutions and workarounds that brought them closer to agile. She first made waves when her suggestion to add more code reviews were accepted by her peers. Afterwards, with help from the APM, she revamped the team’s Jira board workflow. When we talked to Susi, she admitted that her role as engineering lead made her feel responsible for what should be improved.

What about Joko? Compared to Susi whose previous team did not use Scrum, Joko was more exposed to agile practices. For example, he used sprints and poker planning before and he was wondering why the current team did not take advantage of them. When Tono first joined, he did not realize they were straying with their practice. He just felt that they must find a way to improve the product development process. Personality-wise, he was blunt; this helped him become a change agent even though he was the most inexperienced compared to Susi and Joko.

What we found here was that the change agents had the ability to sense that “something is not right” and that it should change. They need to be aware; to feel the pain point firsthand (i.e. the feeling of exhaustion, the never-ending work) and then develop the desire to make things better. This is different with the others who accepted the process as it was. We were curious what made them different from other team members, particularly the ones who were directly coached back in 2016. Apparently, they had different focus; the non-change agents focused only on their technical skills and saw little value in implementing agile practices. They became senior engineers who mentored others in programming and technical design. In contrast, the change agents tended to be more junior and had passion for improving the process. From a coaching point of view, this means that post-coaching the coach needed to make sure that the team members were able to see the difference before and after the adoption of agile practices.

On top of that, the change agents were not afraid to speak up their minds when they felt that something was not right. They brought up the issue to the engineering manager, in which the manager later told them to join the agile guild. We found an interesting thing here: since they spoke to the manager separately, Susi felt that her discontent with the current process was validated after knowing that other team members shared the same concern. She was also willing to join agile guild meetup only if the others were joining. This became important: in this team, the change agents succeeded to change the process partly because they knew that they are not alone. One change agent might not be able to drive the change.

What we like from the concept of change agents was that the change was driven from inside the development team and not from outside, not even from the product side of the team. This is aligned to Agile Coaches’ vision to make teams self-organized. Using the lessons from this team, we can derive the principles of successfully using change agents from inside the team to instigate improvements. There should be more than one team member who is aware of the pain points and have a desire to make things better, who speak their concern, and be willing to implement the change. Currently, the Scrum Master initiative would be a way to encourage change agents in the team. Not only they were supplied with knowledge of agile practices, they are also responsible to maintain scrum practices in the team. Moreover, since the Scrum Master role is rotated every three months, as time goes by, more people from the team had the knowledge and experience to be the Scrum Master, fulfilling the requirement that there should be multiple team members who should be aware of good agile practices.

3.2.2    The fresh perspective

In Bukalapak, Engineering Managers (EMs) are the functional managers of engineers. Together with Quality Assurance managers (QAMs), they are responsible in one tribe, which roughly translated to 20-40 engineers. Their responsibility includes listening to engineers’ aspiration by doing monthly one-on-one and stimulating their learning and growth.

When Susi, Joko, and Tono had a concern about their development process, they knew something was wrong and they separately brought the matter to the EM in one of the one-on-ones. The reason why they attended the agile guild was that it was advised by the EM. In our opinion, there are several factors why interaction with EM became a trigger in solving the problem.

Firstly, since EMs are their functional managers, they are responsible for the engineers’ well-being. When engineers complain about something, they will try their best to provide a solution. Secondly, the EMs could see from a broader perspective. They understand the organization and they know where to look at when someone is having doubts. This is because they are in the middle-management level and they know what was going on in an organization (e.g. the guilds meetups). Lastly, the EMs have a regular schedule of one-on-ones with engineers. This is done monthly and at the very least it should be conducted quarterly.

As the organization scaled up, more functional managers are hired to keep up with the number of engineers. This posed a challenge in sustaining the ability of EMs to see from a broader perspective. In our case, it was a senior EM who had more knowledge about the organization. If he was a newly-hired EM, he might not know what the possibilities were. We have to always sync up with the functional managers so that they refer to agile guild or the Agile Coaches if questions about agile practices were raised.

Moreover, the more complex the organization, the bigger is the functional managers’ responsibility to manage the development and operation process. This posed a risk to the frequency of personal interactions between them and the engineers. It was important to ensure that the functional managers still regularly conduct the one-on-one sessions with the engineers, since this is one of the ways of maintaining agility in teams.

3.2.3    The agile guild

The agile guild’s objective is to facilitate sharing of agile values, principles, practices, experiences, and lessons learned, where anyone can learn and bring back to their team a new, improved way of working that leads to positive impacts. The guild did various meetups in 2018, such as scrum Lego game meetup, agile estimation and planning, the benefits of retrospectives, and also free sessions such as Lean Coffee. The monthly meetups were usually conducted offline. Besides, the chat group was quite active, discussing things from daily stand up chatbots to pair programming.

While this case is the first notable “success story” of a team who reaped the benefits from an agile guild, we as facilitators have observed that other people who attended the meetups also asked questions about problems their teams were having. The questions were not always related to the meetup’s theme. Moreso, we have heard testimonials where concepts introduced at the meetups, for example, scrum simulation with Lego, helped the attendees in their team’s way of working.

What we can learn from the story was when teams wanted to learn more about agile or when they had problems, there was a place to facilitate that. In this case, it was the agile guild. As Agile Coaches, providing this organization-wide support system was crucial since we could only coach a few teams at one time. The rest, however, could always join this community of practice. To complement the agile guild, recently we also launched an initiative where we provide a consultation session to teams that want to discuss more intensively about agile practice. If in the agile guild we facilitate a sharing session to the teams to exchange their knowledge about the agile practice, in this session a deeper discussion about the team’s problem could take place.


The shepherd reflected on the stray sheep’s journey and her experience in herding the sheep.


When we said before that in 2016, “chaos” would be the right word to describe how teams deliver product, we realized that the same thing happened again in 2018. It happened because when we looked at the way agile practices were introduced to Bukalapak, it apparently was not sufficient to sustain a consistent adoption of agile practices. It may be sufficient for the adoption in the early teams, but not organization-wise when the company scaled up. The hard-earned lesson here is the maintenance of agility, both at organization and team level, after the teams are being coached about agile. When agility is not maintained, when people and process are not being regularly reviewed, things will slowly become disorganized and chaotic.

If we look closely to the specific example of the strayed team, the main issue was also maintenance of agility. From organizational level, despite being one of the first teams in Bukalapak, they were not intensively coached by the VP of Engineering. From team level, both the product team and engineering team embraced pragmatism, where processes were the least of their concern. As a result, when they started to stray, nobody knew what was wrong or what to do. Fortunately, they were able to solve their problems by re-adopting agile practices. However, this provides one important conclusion: that teams are able to re-adopt agile practices without being intensively coached.

If we revisit the way the team re-adopted the good practices without being (intensively) coached, there are three important things to learn:

  • The agents of change and the three factors that enable them. First, the change agents should be outspoken, which means that we as shepherds should encourage the culture of speaking up in the organization. Second, there should be multiple change agents in a team. Third, the change agents should be given responsibility, which we have addressed through the role of Scrum Master.
  • The functional managers’ perspective: the shepherd’s homework in this area is to always sync up to the functional managers about agile in general and to ensure that the personal interaction between the functional managers and their subordinates takes place.
  • The organizational support: whether it is in the form of a community of practice or the availability of “your friendly neighborhood Agile Coach,” teams need to have a place to turn into when they encounter problems.

Currently, the way we tried to maintain agility based on those three points. For example, Scrum Masters have contacted Agile Coaches to ask about their team’s problems. Functional managers have also referred people to the Agile Coaches, and more teams have joined the agile guild to consult about challenges in their team.

The lessons learned from this case study are applicable to agile practitioners. It is for teams that already understand and apply agile but having problems with it, teams that stray after adopting the practice, or even teams who have no idea how agile works. This mechanism doesn’t guarantee that the team will not be straying in the future, but at least there is a shepherd (Agile Coaches in this case) and a “fence” that will keep them from straying too far from the flock.

One last thing: during the writing of this paper, we realized that there are many different narratives that help us to see the problem as a whole. Apparently, the same events were experienced differently by different people. Our main observations and insights remain the same, but we have gained a deeper appreciation for the complexity of some of the issues. For example, one of the questions that we sent out to research is “why”: why did teams stray? We found that everyone agreed that they strayed because agile practices were not maintained. So we again asked “why”, why were they not maintained? The VP of Engineering told us that he had given the directive to the PM to implement the required behaviors and had previously coached the engineers who later joined the team. However, neither the PM nor the team members maintain the practices. The PM did not fully follow up and the team members did not understand the importance of implementing agile practices. And so on, and so forth. This help shaped the report in an unexpected but beautiful way.

5.     CLOSING

And then they live happily ever after…


After retracing the stray sheep’s journey, the shepherd had known where the once-strayed sheep went. It jumped over the fence and walked to the forest through the muddy river. Fortunately, it was still the outer ring of the farm, where another fence was installed. By walking along the outer fence, the sheep was able to find its way home. The shepherd, realizing that the outer fence that was originally used for preventing the wolf from approaching the inner farm helped the stray sheep to go back into the flock, installed more outer fence along the side of the farm. Hopefully, it would help other sheep to find their way back home. The farm owner did not worry anymore about the stray sheep, and the shepherd and the sheep continued to live happily ever after.


This paper would not be successful without Avraham Poupko’s guidance. Our weekly Skype session really helped us to see the story from different points of view. Avraham, thank you very much for all your support and feedback! We would also like to thank Ibrahim Arief for his initial feedback to the proposal and the very long talk about the introduction of agile practices to Bukalapak. Moreover, we’d like to thank Radhy M. Ampera and Brahmastro Kresnaraman for proofreading. Also, thank you to Bukalapak team: Cita, Sharon, Maul, Farhan, Bayu, Andrew, Rizki, Hadi, Sarah, Ai, Awal, Ella, Imam, Malik, and Dennice. You guys ROCK! Lastly, we’d also like to thank Agile Alliance Experience Reports committee: Thanks Johanna Rothman for our proposal’s first feedback and thanks Rebecca Wirfs-Brock for all the guidance!

About the Author

Currently a Release Train Engineer at Eurail in Utrecht, The Netherlands 😉

Chief of Staff to the CTO at GovTech Edu. Supporting the initiatives of Indonesian Ministry of Education, Culture, Research and Technology