Introduction

Hello everyone! I am Kin-chan from the KINTO Technologies' Development Support Division.

I usually work as a corporate engineer, maintaining and managing IT systems used throughout the company.

The other day, I presented the "Study session in the format of case presentations + roundtable discussions, specialized in the corporate IT domain" at the event "KINTO Technologies MeetUp!" 4 case studies for information systems shared by information systems -"

In this article, I will introduce the content of the case study presented at that study session, along with supplementary information.

The Presentation

You can check below for the full presentation material (in Japanese):
[An Introduction to AGILE SaaS] The Secrets to Achieving Maximum Results Quickly with Minimum Workload

In addition to the slides I used in my presentation, I will provide additional information to clarify any difficult parts and cover topics I couldn't address at the event.

Title Selection

First of all, I'd like you to examine the title.

Many people interpret "Agile" in different ways, making it daunting to include in the title of a presentation.

However, I chose to have it anyway because I hope that someone who listened to or saw my presentation might gain insights like "Oh, so this can also be considered Agile" or "It's not such a difficult topic," and inspire them to take new actions.

(Of course, the fact that it's an "attractive" keyword was also a factor in my decision.)

What I Will vs. Will Not Speak About Today

Since I used the keyword "Agile" in the title, I thought it would be good to focus on content that can be linked to the value of Agile software development.

If you're interested in hearing more detailed information about processes or the small stories that occurred during projects, please consider joining KINTO Technologies.

Background

The introduction of IT Service Management (ITSM) tools, which include inquiry and request management, began with the IT team. Due to its relatively smooth implementation, there was a basis for extending it to management departments beyond IT.

Before this flow was established, there wasn’t many opportunities to interact with "other managing departments beyond IT" within the company.

Personally, I had previous project experiences with many non-IT departments, including before my previous job. So, when I was appointed to drive this project, I felt glad because I thought I could leverage my past experiences.

The decision to opt for an Agile approach stemmed from the background of having a rough goal in mind but not having concrete set of requirements or functions established, and wanting to achieve success with minimal workload while still creating value. Instead of a rigidly defined phased implementation (as one would do in a Waterfall model), the Agile approach, which involves iterating through dialogue and course corrections while building minimal viable products, seemed more suitable.

I have this slide here that says, "I think it's better to go Agile!" It might seem like we had already decided on Agile from the project's inception, but in reality, it was more like, "Hmm, how should we move forward? Let's start by listening to what the stakeholders have to say."

It was after conducting hearings with the Administration Department team members that we gained a sense of, "With them, we could proceed with this style!" which led us to adopt the Agile approach mentioned later.

About Agile

When someone asks me "What is Agile?" within the company, I typically respond with something like, "It's a state where work progresses by focusing on value while iterating Kaizen (continuous improvement) in short cycles."

While those familiar with software development may understand the values and principles outlined in the Agile Manifesto, others might not resonate with it.

Lately, I've noticed that explaining Agile has become easier with the publication of books like 'The Agile Kata' and other Agile books targeting non-IT audiences.

As for the progress of the project...

For the next slides, I made a conscious effort to explain "What makes it Agile?" in a way that links back to the values outlined in the Agile Manifesto as much as possible.

The message I wanted to convey with this slide is the establishment of mechanisms to minimize unnecessary communication and facilitate immediate engagement in essential conversations.

In typical software development scenarios, one common question might be, "What tasks are currently being performed?" and for clarifying "What do we want to accomplish?" .

Given that this is a "SaaS implementation with a certain degree of framework already established," I deemed it more appropriate to explore "effective usage based on the existing framework" rather than "defining requirements based solely on current tasks."

Furthermore, one of the strengths of low-code tools is their significantly lower cost for the build-break-fix process in the initial stages. This made it feasible to create a prototype providing minimal value before the first meeting.

As a result, instead of starting the conversation with "So, what kind of product do you want to create?" during the initial meeting, we were able to begin with discussions focused on specific functional prototypes, asking questions like "How about a system that works like this? Do you notice any issues with it?" This allowed us to engage in discussions centered around tangible, functional examples right from the start.

These aspects focus on the following values in the Manifesto for Agile Software Development:

• Individuals and interactions over processes and tools
• Working software over comprehensive documentation

What I wanted to convey in this slide is “to create value at short intervals, get feedback, and create a mechanism to provide a system that makes sense”.

One common aspect in meetings is taking points as homework for internal discussion later. For example, "consider what kind of menu structure is good" or "discuss internally what kind of process flow is best".

But this time, rather than leaving such "takeaway considerations" entirely to the other party, we opted to participate in these discussions by being invited as guests to their alignment sessions.

By doing so, we can immediately address any questions, concerns, or discrepancies that arise during the conversation, and we can swiftly provide answers or even start making system adjustments on the spot.

As a result, despite being in a "separate discussion" setting, we were able to progress not only with specification changes based on the discussions but also with actual functional improvements.

Furthermore, I mentioned here that "significant specification changes emerged at this point," but what I meant was that we were able to detect a situation where it was more beneficial to essentially "start over" rather than modify what has been done so far. Of course, this meant discarding what has been built till that point. However, by actively participating in the discussions, we were able to fully understand the necessity and value of rebuilding. This allowed us to make this decision with confidence.

These aspects focus on the following values in the Manifesto for Agile Software Development:

• Customer collaboration over contract negotiation
• Responding to change over following a plan

Finishing the project

Through this project, one of the most significant gains I feel I've obtained is "trust."

It's just my unilateral opinion, but I feel that I've contributed to creating opportunities where people think, "Working with this person leads to good results," and "I'd like to consult with them again if there's something next time."

Certainly, I believe there are many approaches to project management that can yield positive results, not just those aligned with Agile practices like the example we discussed.

But If you ever find yourself stuck on how to proceed, I recommend considering the values inherent in Agile as a reference and trying to adjust your actions just a little:

• Envision your desired outcomes and apply small changes to achieve them.
• Observe the results of those small changes in behavior and use that feedback to further refine your vision of the desired outcome.
• Continue to make further small changes in your behavior.

Once you're able to repeat this process, it's safe to say you've adopted an 'Agile' mindset.

Conclusion

As mentioned at the beginning, I hope to inspire anyone who has gone through this material to gain insights such as "Oh, this is also Agile" or "It's not such a difficult topic". I would be happy if this can serve as encouragement for your next actions.