STORES Product Blog


A RSGT2023 First Timers Report


Hello everyone! My name is Adam Henry and I am an iOS Engineer and CSM at STORES Inc. I found out a little bit too late to join the offline event but I wanted to write about my RGST2023 experience! Reading all the books in the world will definitely up your knowledge about a subject but actually hearing things being put into practice and the successes and failures of each one is invaluable. I summarised the talks with a few graphs or images with my thoughts below. Would love to know what everyone else thinks.

The Keynote

The Keynote is from David Bernstein. It focused on five key development practices from Extreme Programming.

These five practices include automating the build for continuously integrating software as it is written, collaborating with team members through pairing and mobbing, practicing agile design skills that enable testability, using test-first development to make code independently verifiable, and refactoring code to reduce technical debt.

He came out with some really surprising statistics on the current state of software development. 80% of time spent is undoing decisions made during the first 20% of that project's development and that 43% of all features go totally unused. There has to be a better way.

Everyone hates working with Legacy code because it breaks when we touch it.

I feel this part in my soul. Having past experience with an extremely mature codebase with over 1,000,000 lines of code breaking things was a daily occurrence.

The only software that doesn't need to change is software that no one uses which is why untouchable legacy code shouldn't exist.

So many great quotes in this talk that speak to big problems in many code bases.

He talked about Continuous Integration in terms of committing to trunk multiple times daily but it is a little different from what I imagine when I hear the term. I never thought that feature branches broke that convention if you set up your CI/CD flow correctly 🤔 As a mobile dev I couldn't imagine the nightmare that would happen in that scenario 😅 Would love for anyone to correct me on that.

Nine Essential Practices

All in all there are nine different Essential Practices but his talk at RSGT2023 only focused on the five most important ones They are as follows:

1. Say What, Why, and Whom before How
2. Build in Small Batches
3. Integrate Continuously
4. Collaborate
5. Create CLEAN Code
6. Write the Test First
7. Specify Behaviors with Tests
8. Implement the Design Last
9. Refactor Legacy Code

Integrate Continuously

Integrating continuously it is important because when you put off something until later the switching cost of looking over the code again and getting into that mindset wastes time especially for large codebases.

So when the build breaks the team's main focus should be fixing it. I have never seen a team work like this before so it would be awesome to see a team in action. Not sure how it well it would translate to mobile though. He talked about UI testing in his examples a bit but with iOS, the project file conflicting, long build times, heavily dependent on UI so it is difficult to test and the costs do not outweigh the benefits a lot. I would love to see an example of this working well somewhere but a lot of times UI Testing is thrown away for how flaky it is.

Definition of Done

This is a really important thing to talk about as a team when communicating requirements and creating tickets/stories. What is needed for the ticket to be able to be closed.

- Done: works locally
- Done-Done: Merged and working
- Done-Done-Done: Merged, working, and refactored of tech debt

In my personal opinion (it may not need to be said) is that requirements are met in there somewhere. In a tight schedule I think a lot of teams stop at Done-Done. (I can attest to not getting as far as refactoring sometimes😇)


Extreme Programming

Extreme Programming uses an open workspace with lots of whiteboard space and lots of pair programming stations.

Developing Software is a collaborative act. We need a shared understanding of goals and approaches. A shared understanding of quality and definition of done.

2 Types of Collaboration: 1. Pairing 1. Buddy Programming 1. Last hour of the day get together and Review the code together 1. Mobbing 1. Spiking 1. Researching a problem's unknowns with one or more people 1. Swarming 1. team works to solve the same problem 1. Mobbing 1. team works together on the same story

Working together and the ability to help others understand is a necessary thing not just having a specialized skillset. Eliminating the bus problem and having knowledge spread throughout the whole team is very important. A great way of doing this is mobbing and pairing.

I have tried Mobbing/Pairing before and I definitely see the merits I am not sure if I could do it full time. I think a balance is important for most people. In the past we only did it when the bus factor was too high so that person had to share knowledge with the rest of the team or when tackling a particularly hard problem.


  1. Cohesive - Single Responsibility Principle (SRP)
  2. Loosely Coupled
  3. Encapsulated
  4. Assertive
  5. Non-redundant

All of these principles and how they tie into testability are part of all good developer practices.

Writing Good Tests

He also talked a lot about writing good tests. Many companies (at least in the mobile world) I think don't write tests/have the bare minimum so it might be a good thing to invest in for all devs to take a look at.

A good test needs three things:

  1. Test only fails for the reason you mean it too
  2. Doesn’t fail for any other reason
  3. Isn’t duplicated by any other test

In other words, a test should be unique.



Technical deadbeat - pay off technical debt as soon as you can (like paying off your entire credit card each month). I wrote most of this in English but the Japanese here is too good (for those living over here).

Refactoring Techniques:

  • Pinning Tests - Create large end-to-end test called a pinning test to pin down current behavior before refactoring
  • Dependency Injection
  • System Strangling - replace a component while its working and slowly create new implementation from the old interface
  • Branch by Abstraction - feature flags

Final Thoughts 🤓

I wrote a lot of things just from the keynote but he touched on alot of great topics with alot of good advice. One of the big things that stuck out to me though is that 10% of the whole industry are doing TDD/XP and that most of them that do it are doing it wrong. Why is it so hard to do that most of these teams fail and many more are afraid to even give it a try.

Pairing and Mobbing in my limited experience has been a great way to share knowledge, experience and just seeing how other members of your team do things in the day to day. Especially in the post-covid/corona world where everyone is remote.

Recommended Books:


Examples of Output vs. Outcome - Output is a feature we made. For example in our POS Register app we added a feature to allow owners to add a QR Code to the receipt) - Outcome is something that effected our users, fixed a problem, etc. ie. Customers found the Net Shopping page for that shop from the QR Code and bought an item they were interested in.

We need to not just focus on lots of output but also that outputs outcome.

What happens when we don't focus on outcomes

  • We might make something no one uses
  • The people involved will lose motivation because they don't understand why these features are being made

A big problem when there is not enough communication or logging in our features to see if they are actually being used.

3 steps to become outcome focused

  • Give the team time to learn the necessary skills
  • Let that team get into an output rhythm
  • Create an Outcome focused team to follow the first teams output

It is easy for these teams to become tribal so any goals should involve both teams and the entire flow should be readily visible to both teams.

Definitely a problem I have seen in the past with teams that split off like this, even when a member of that team had been part of the original team for a long time. Would love to hear some techniques to alleviate this problem from others who have had this happen as well.

Final Thoughts 🤓

The biggest takeaway is that we cannot just keep adding features and releasing them to the user without looking at the impact/reaction of our users. It is not a one-way street. It is a feedback loop where the outcome of one release should inform subsequent releases.


We cannot focus only on the outcome but the business impact and worth to our organization. So when looking at the bigger picture we cannot just stop when looking at outcomes. This talk takes things a step further than the last one.

Build the right thing, Build the thing right

Another great quote! because they are both important parts of the process!

Final Thoughts 🤓

This talk focused on how to take the data available to us as a team and visualize the different processes. In my personal experience once the data builds up Scrum Masters can show their team that the cycle time of tickets have leveled off instead of having large variations meaning their estimates for tickets are on point and tickets are split up properly. And when a sudden spike appears we can retrospective about what happened and fix things in the next sprint. Not to mention when asked for estimating when a new feature could be feasibly developed we can use these past values to see how much can be done in what amount of time.

All The charts mentioned in this talk are really useful! Please take a look!


As an engineering manager you need to look at the company's profits AND PEOPLE. They should look at not just the short term profits but the long term ones too.

What should a first time Engineering Manager look at?:

  • Business: Understand what your teams business results should look like
  • People: Get to know your team members
  • Durability: Team Building

What you are responsible for in each category:

- Business
    - Business Strategy
    - Organizational Goals
    - etc.
- People
    - Team's Status
    - 1on1
    - Performance
    - etc.
- Durability
    - Hiring
    - Process Improvement
    - Documentation
    - etc.

Final Thoughts 🤓

In the future I want to give Engineering Manager a try so this talk was a really good look into that world. So far I have had some experience in the People and Durability so seeing what is needed on the business side was a lot of help!

”エラい人”にチームの状態を見える化セヨ 〜組織にアジャイル浸透の輪を広げる チーム状況の定義/可視化/運用 のアイディア共有〜

3 things to think about when starting a project:

  • Is there an allotted skill acquisition time?
  • Do things just end with no retrospective look back?
  • What is the definition of done?

I have never really heard the skill acquisition portion brought up before! Only one project I can think of where the team had this built into the project. 🤔

Skill Acquisition

In the talk he mentioned some good advice for the skill acquisition phase. Definitely good rules to follow.

  • Set a time limit for the skill acquisition
  • Make sure they understand that it isn't a hard schedule but a goal
  • Of course even if you temper expectations they will still unconsciously become expectations
  • So do not repeatedly lengthen it without good reason

Definition of Done

Don't report progress, Report the state of things

Remember this for later ✍️

Three steps to achieve better visibility for your team:

  1. Set the scope
  2. Make the team's status visible
    1. With a task board showing the teams progress or other progress tracking metrics
    2. To Do, Doing, Done
  3. Share status with a 3rd party


I think a lot of teams struggle on how to make their progress/work visible to higher ups and other teams.

Some benefits of making the teams activities include:

  1. Team's Visible State - Makes it easier to explain what is happening with the team and makes it easier to see what to do next.
  2. Growth - Using the trend info it is easy to see and explain where to challenge something new or make an improvement
  3. Unexpected Discoveries - Becomes a topic of retrospectives (Makes it easier for the team to notice a trend happening within themselves and the Team can notice some organizational issues that aren't just limited to the team itself)

One of the biggest things explained was not just making it visible for others but within the team itself so the team can grow and improve. If your team has no way to measure itself or visibly see improvements it is really hard to see why we do Agile in the first place. Show and explain the data to your team regularly!!!

Final Thoughts 🤓

This is always something I have had trouble with. How to make the team more visible and appeal to the higher ups outside of the team. Because it often boils down to I don't understand mobile or something along that lines and some things are hard to put into numbers. Great talk with great evidence why the data that we acquire while doing agile/scrum is so important.

Effective Retrospective++~楽しいだけじゃない、次の一歩を自分で踏み出し続けられるふりかえりへ~

The first time I have ever seen so many people on 1 Miro Board.

What is a Retrospective

A retrospective is an activity where the whole team stops and talks about a better way of doing things, and changes the behavior of the team little by little. It's not an activity to look back and have a reflection meeting or feel bad about something. It's an activity where everyone looks forward, comes up with lots of ideas, draws the future, and brings the future closer to reality.

Retrospective Flow:

  • Step1 - Prepare the Retrospective
    • Prepare an activity on Miro or other whiteboarding tool
    • Think of what the team should talk about
    • Decide who will facilitate the retrospective
  • Step2 - Create the Retrospective Space
    • Create a space where members can focus on the retrospective
    • Make sure it is a safe place to voice their real opinions
    • Get a consensus of the theme/goal of the retrospective
  • Step3 - Remember what was accomplished in the Sprint
    • Put everything the team remembers up on the board
    • Let the team share what they remembered
    • Make sure to put up any important words the members say as they are sharing
  • Step4 - Brainstorming
    • Think of what the team should do next, what the team should include next time
    • There are no bad ideas, put everything up on the board
    • Be careful labeling ideas, especially with negative words
  • Step5 - Decide Actions for the next Sprint
    • SMART is important here (Specific, Measurable, Achievable, Relevant, Time-bound)
    • This should decide the team's actions, individuals can decide what they will do themselves
    • Try as soon as possible, there are many things that you won't know until you try
  • Step6 - Improve the Retrospective
    • How was the goal and them of the retrospective
    • How could the team have had a better discussion in regards to the problem
    • Make sure tries are in a place where the team will see them regularly
  • Step7 - Act
    • Start acting on the decided Actions from the retrospective immediately, add it to the backlog
    • Not all actions will have a positive effect so always retrospect them

Final Thoughts 🤓

As a CSM for about a year and a practicing SM for about 2 it is easy to look over alot of the detailed points from above. It is always a good idea to go back and look at the basics and work up from there. One of the most important things I heard in this talk was that even if the retrospective runs out of time, if the team is having a great discussion there is no need to stop it to return to the retrospective. Because if the team is having a discussion in the retrospective it is important and can lead to important actions and noticing something from within the team. Creating the Retrospective Space is really important because if the team members are distracted with other tasks then they are not focused on the retrospective. I heard DPA for the first time but I am unsure what the difference is between that and working agreement 🤔 I should have asked that question 😅

RSGT 2023 Summary

This entry has run a little long 😅

Over all the talks that I listened to a recurring phrase was said that is stuck in my head. Don't use velocity, cycle time, etc. in reviews for individuals for promotions and raises. This has always been hammered into me as well when starting my agile journey. This is something that I have struggled with and would love advice from others on how to set measurable goals for individuals inside the agile/scrum framework. I would love to hear from some Engineering Managers that have fought with this problem before and has any insight.

I couldn't join the in person event so I couldn't do much collaboration but next year I would love to meet other Agile enthusiasts and talk shop! I heard many great ideas from team level Scrum all the way to the organization and I cannot wait to give them a next try and maybe talk at an event in the future. Still so many videos from sessions that I wasn't able to attend to watch! See you at RSGT 2024!