Project description and scope

The project started off inconspicuously: a Buddhist monk approached us for support with a website collecting early Buddhist texts and their translations. His endgame was to provide a library consisting of ~20,000 texts in 41 languages. He had a functional site he was looking to improve with his redesign ideas and mockups, and for that purpose he sought outside help.

SuttaCentral didn’t have an exact road map of where the project was supposed to go, so we helped them shape the development work on the product. It allowed the team to get on the same page from the start and have a clear understanding of the goals we were to accomplish.

Even though initially we were supposed to handle only the backend, we quickly ended up working also on the frontend due to the amount of work and new design solutions. We didn’t build the product from scratch, instead taking what SuttaCentral had already had and modifying it.

Progressive Web App

The client was interested in building a Progressive Web App (PWA) to enable offline functionality. That and the mobile component were both important to SuttaCentral, since they wanted their product to be easy to access, simple to use, and available to all—especially in places with poor Internet connection or lack thereof.

We were concerned the challenge could prove too great for us, since we hadn't done an app like that before. We were upfront and honest about this with our client from the start; they put their trust in us all the same.

In the end, it worked wonders for both sides, giving the client exactly what they had hoped for, while giving STX Next a unique opportunity to prove our worth on uncharted waters.

Team composition

We worked in an international team of 7: 4 people on our end, 3 on the client’s.

The 4 STX Nexters assigned to the project were: Hubert Dworczyński, Jakub Semik, Krzysztof Woźniak, and myself.

Hubert and Jakub were in charge of the frontend and the backend, respectively, bringing to work bucketloads of energy and passion for their craft every day.

Krzysztof handled testing and provided QA support, keeping a close watch over our progress and always looking out for every mistake or inconsistency.

Lastly, the role of Product Owner was mine to fill, and I made good use of all my product and project skills to best serve the client.

During the first month, we also had a little help from Wioletta Jaźwiecka, but the core team on our side was the 4 of us.

SuttaCentral’s part of the team was led by the company’s co-founder Bhante Sujato, who was a great mentor to all of us for the duration of the project. Supporting him were backend developer Blake Walsch and frontend developer Ayya Vimala.

A success story

Working with SuttaCentral has been an absolute highlight of my professional career, and I’ve been doing this for a while now.

The experience was so rewarding that it has stayed with me to this day, frequently revisited in my head with the fondest of memories. And it wasn’t just me; our whole team felt that way. A success story if there ever was one, in every sense of the word.

But, like every great success story, this one, too, was a product of a multitude of factors, only made possible by doing a lot of things right and working as a team to accomplish our goals.

If you wish to learn the factors that made the story of STX Next and SuttaCentral a success—read on.

Working Agile with the 3 pillars of Scrum

The very first thing we discussed with our client was how we were going to work together as a truly blended team. Quickly and easily we came to an agreement that the best practice for our everyday future cooperation would be the 3 pillars of Scrum: transparency, inspection, and adaptation.

We applied the philosophy of Scrum both to our development process and the discussions we held with each other. Let me tell you a bit more about each of the pillars and what it meant for all involved.

Transparency

We were having daily Scrum meetings with our client, carried out with full transparency. Every aspect of the work was out in the open:

                     
• what we couldn’t do and why;
                     
• what we had never done before, but were happy to try;
                     
• the mistakes we had made and the lessons we had learned.
                   

The process was a constant back-and-forth between us and the client. All 7 team members supported and helped one another to execute better, deliver better, do better.

And the best part? It all came to us naturally. Staying open, respectful, committed—sometimes even courageous—was never an issue and never got in the way of getting work done. On the contrary, it allowed us to grow and learn, and I, for one, have been benefiting from the education of that project ever since.

Inspection

All-around feedback was central to the work we did with SuttaCentral. The 4 of us on STX Next’s side and the 3 team members from SuttaCentral got along extremely well; we gave and received constructive criticism, exchanged notes, and reviewed each other’s code on a regular basis.

In fact, our dedication to continuous performance improvement went as far as having 1-day feedback loops between the team and the client on each of the tasks. But that’s not the end of it! We went one step further still.

We were implementing changes to the website based on feedback collected from the SuttaCentral Discourse forum. Truthfully, the product wouldn’t be what it is today if it hadn’t been for the input from these lovely people. So it’s not a stretch to say that the client’s site was created not only for, but just as much with the people it was designed to serve.

Adaptation

When feedback never stops, your ability to adapt becomes your greatest asset. Without the follow-up, all the notes and suggestions are just empty words. It’s not the theory, but the practice that matters.

With SuttaCentral, we had to adapt all the time—and we loved it. Corridor testing gave us new findings, or option analysis yielded new results? We reviewed them with the client, decided on the ones to implement, and did just that.

The feedback never stopped, and neither did our capacity for adaptation. The solutions changed virtually after each development cycle, and we went out of our way to meet the client’s expectations.

In the end, their happiness was our happiness, and the Agile methodology we worked with resulted in genuine partnership between all the team members, on both sides.

Product discovery

SuttaCentral was my first project at STX Next. That alone made me excited to get right to work, but imagine how over the moon I was when I learned that this first project of mine for our company was going to be for a non-profit organization!

The realization came with a need for reprioritizing, though. Before anything else, we needed to decide on the approach, and asked ourselves:

How should our approach to a non-profit organization differ from a for-profit one? Which product techniques would serve this client best? How do we measure the success? And so on and so forth.

In no time at all, with the help of our Product Design team led by Wiktor Pawlik, I had more than a few ideas. Thankfully, they worked out quite nicely.

Here are the techniques we used to structure our product work, along with a short description of how we benefited from them.

Product Vision Board, target proto-personas, and user journey mapping

We started with Product Vision Board and competitive analysis. For the purposes of this project, we referred to the latter as “comparable websites analysis,” following an eye-opening discussion on what “competition” is to Buddhists.

This provided us with a much-needed understanding of the product we were building and a solid foundation for product development going forward.

Following that, our next step was to create target proto-personas for the services provided by SuttaCentral and map out the user journeys.

It’s always good practice to have both done very early on in the process and keep them handy at all times throughout project delivery. Doing so helped us keep our focus where it needed to be—on key user needs—every step of the way.

Additionally, it allowed us to take a step back from our initial assumptions and rethink some of the features that turned out to be not as crucial as we had imagined at first.

User story mapping

Once we had acquired a sufficient understanding of the product and its users, we were ready to enter the next phase of development, which meant:

                     
• splitting the scope;
                     
• creating user segments and user stories;
                     
• drafting the first story map.
                   

With that information in hand, we could run our first estimates and develop our first story map and roadmap. Thanks to the story map, we were able to determine the dependencies between tasks and open points or questions to be answered later on. The roadmap, on the other hand, gave us a clear picture of the work that lay ahead.

All of the above was hugely valuable.

Well-defined user stories were crucial for effective and efficient teamwork, helping us keep our eye on the ball whenever doubt crept in. A straightforward roadmap, on the other hand, did wonders for client trust and confidence, giving them full insight into how the work was progressing.

I seriously couldn’t have imagined working without these two.

But you don’t need to take my word for it; take a look at the story map draft we created during the third day of our discovery workshops and see for yourself.

I’ve heard people say that these kinds of workshops only make sense during the earliest stages of project development—nothing could be further from the truth, if you ask me.

Everything we had discovered and established early on in the process paid dividends for us in the long run—arguably more so than in the beginning—whenever we considered implementing new features. That being said, I do see value in putting more emphasis on the workshops when the work is still in its infancy.

Understanding the requirements of a Progressive Web App

Since the discovery workshops for user story mapping were a gift that kept on giving, we decided to repeat them when the time was ripe to begin implementing the functionalities of a Progressive Web App into the product. Essentially, this meant providing the word of the Buddha not only online, but also offline.

We benefited from 3 techniques for defining PWA functionality the most: Problem/Solution Fit, Minimum Viable Product, and a detailed Progressive Web App story map divided into phases.

Problem/Solution Fit

The Problem/Solution Fit approach answered a fundamental question for us:

Why did SuttaCentral need a Progressive Web App?

The answer was simple: unlimited access.

Imagine living in an area where Internet connection is extremely expensive. Or one where you need to walk to the nearest village for several hours to get free Wi-Fi. Or one where there is no Internet at all.

Those were all problems we had to address, because that was precisely what both our client and our target personas had been dealing with. A PWA was the perfect solution.

Minimum Viable Product

Another beneficial aspect of using the Problem/Solution Fit was narrowing down our focus for the SuttaCentral Minimum Viable Product (MVP).

The ability to build a successful MVP, especially under severe time constraints, is no small feat. Luckily, STX Next has had considerable experience in the field, with SuttaCentral being but one of many examples.

What makes me especially proud is that by the time we got around to doing the MVP for SuttaCentral, our team had learned quite well the ins and outs of what an MVP is, how to build it, and how to differentiate it from product enhancements.

Progressive Web App story map

Using all that knowledge and experience, it was effortless for us to outline 5 steps of the PWA development. The MVP was the first step, followed by 4 product enhancements specifically tailored to this functionality.

Another point of pride here for me, personally, was the way our approach influenced our relationship with the client: after each step, we had a working product, ready to be released without any need for further development. Naturally, this was done in the interest of further transparency and maximal benefit for SuttaCentral.

However, it wouldn’t have been possible if we hadn’t tried a number of different ways to tackle story splitting, done plenty of refinements along the way, or had a really solid grasp on the workings of our PWA MVP.

“A picture is worth a thousand words,” as they say, so to give you an even better idea of how we worked, here is an overview of the PWA story map:

Overcoming the cultural barrier

I’m not going to lie—I was lost and out of my depth during the first few days of working for SuttaCentral.

The foreign nature of the project played a major part in that. I mean, just look at some of the terms we were working with on a regular basis: Sutta, Vinaya, Abhidhamma, Dīghanikāya, Sīlakkhandha Vagga, Bhikkhu Vibhaṅga, Pārājika, Dhammasaṅgaṇī, etc. It’s more than enough to make your head spin, especially if you come from Poland, like I do!

In light of that, a burning question arose:

How do we find ourselves in all that new information?

Internalizing this unknown cultural context was of paramount importance, no matter how big a challenge it may have presented. Thank God (probably not the best choice of words here), I came across a mind mapping technique that greatly helped my team and I structure all the story splits.

Mind mapping

Using the mind map, I began putting all the puzzle pieces together—little by little, one by one—and before long we managed to wrap our heads around the subject matter and familiarize ourselves with the previously unfamiliar.

It wasn’t easy. Early on, my team would ask me more than a few times how I was handling the situation so well. But their insecurity only lasted so long, and in no time at all they had gotten much better at it than me.

At the risk of sounding obvious, let’s ask ourselves:

Why was this a success factor?

Because business is never just business; the more you understand your client, their product, and the needs of both, the better your cooperation will be on every level.

Thanks to us getting a grasp on the subject matter we were working with and its cultural context, we were able to speak the same language with our client. This allowed to us divide and conquer, splitting our work in business logic, which in turn resulted in more effective iteration delivery with higher business results.

For reference purposes, here is the first version of our PWA content mind map:

Looks complicated? Believe me, this is just the tip of the iceberg.

This high-level introduction was only enough to give us a rudimentary comprehension of the content at best. The next step was much harder, as we had to understand the parallels.

Parallels

Parallels are relations between the texts. They allow the reader to navigate through the teachings of the Buddha collected by SuttaCentral using the correlations found in the texts themselves. Parallels hold the greatest value for intermediate and advanced users of the product.

Guess how many parallels there are on the website.

100? 1,000? 10,000?

Maybe 100,000?

Nope. The answer is... 415,621.

Let me put that into context for you. Below is a graphical representation of a tiny, tiny portion of the parallels (made possible thanks to a new graph database we had implemented for this project).

How tiny, you may ask? It’s 6‰ of the parallels, to be exact.

I’d like to congratulate the entire SuttaCentral team from the bottom of my heart for spending years on end finding and matching all the existing parallels with one another. You were the ones who made this happen; all we did was put the pieces together and input them to ArangoDB.

Improving software development by learning and adapting on the go

As I’ve mentioned before, throughout the duration of the SuttaCentral project—from start to finish—we made a point of learning from our mistakes and adapting to the changing circumstances after each and every sprint.

Doing so had a direct influence on the quality of our software development, improving it vastly, to the satisfaction of both us and the client. All of this was done in line with the philosophy of continuous performance improvement.

I think at this juncture it’ll be best if I stop describing the many methods we used to improve our performance. Instead of telling you, how about I show you?

Below you will find tables and figures illustrating our workflow with SuttaCentral.

I’ll let the images speak for themselves.

Product Increment review and Agile roadmapping

During each Product Increment review, we made time to take a good look at our roadmap and adjust it accordingly. Reprioritization happened quite often, and plenty of estimates were made to support said reprioritization.

The purpose of this was to give the client regular updates and provide them with fresh material for discussion. It also gave SuttaCentral certain leeway to make informed decisions and suggest the best ways to proceed with the work.

Scrum was there at each step, guiding us along the way, and we made it a point to keep the process as Agile as possible.

Yet again, don’t take my word for it—see our development roadmap for yourself.

The end-user perspective

Last but not least, the end-user perspective.

For the SuttaCentral project, we decided to experiment with user testing by making it the simplest possible. With that in mind, we turned to corridor testing in order to get quick feedback from users in the form of impressions and opinions.

We adapted and followed the principle that the best results would come from testing just a handful of users and running as many small tests as we could afford.

We picked several Polish representatives from a globalized segment of potential target users to be our sample target group and ran the tests with them.

The findings in that group of 8 were most interesting and helpful. As it turned out, 5-6 of them could immediately pinpoint specific challenges getting in the way of their user experience.

With those results at our disposal, we would pick 2 of the most pressing suggestions from our sample user group and get to work on implementing the change.

Final thoughts

Alas, the day had to come when our work with SuttaCentral would end.

We went live.

During our final review meeting, we received a round of applause from the first users participating in the presentation of the live version.

It was sublime. I still find it quite moving.

Here is a memento of that joyous moment:

And that, as they say, was that.

The SuttaCentral project may have reached its conclusion, but there is no doubt in my mind that the incredible memories we made on the way—both professional and personal—will stay with us all for a long, long time.

I know for a fact that I will always look back on our time together with a smile on my face. And I dare say the client feels the same way; they even acknowledge our team of STX Nexters on the finished site!

One last thing: the client has recently celebrated SuttaCentral in Sri Lanka. Here are a couple of pictures from the event:

Thank you for reading our case study of the SuttaCentral project. It was nearly as enjoyable to write about it as it was to actually do it.

If you’d like to learn more about the services we provide at STX Next, visit our Portfolio and read up on other examples of successful cooperation with our clients.

And if you enjoyed this blog post itself, feel free to subscribe to our newsletter and get fresh updates the moment we have them for you.