社員と会社の関係だけではなく、働き方も変わりました。
例えば、アメリカでたくさん大きい会社には十二月まで社員が事務所に行けないです。だから、会議とトレーニングが変化しなければなりませんでした。コーチとしてそれは私の仕事です。

この発表には、新しいと役に立つのスキルでRemoteの会議とトレーニングをパーワーアップしましょう！

COVID１９が現れた後で、働き方法が速く変えました。アメリカの会社には、社員が時々Work From Home (WFH) (在宅勤務)出来る文化が多いけど、毎日の働き方法は事務所にいると同じです。

今は違います。皆んなの安全のためにたくさんの会社はWFHだけのモードに変化しました。だから新しいチャッレンジも現れました。

このプレゼンテーションでコーチとして私がWFHの普通な問題を直す方法を教えます。

例えば：

• コムニケーション
• 同僚と絆
• テクノロジー
• Burnout/Exhaustion

COVID19 has changed the way we work. While many American companies had cultures that supported occasional work from home for employees as needed, the culture of working remained the same as when those employees were located in offices.

Now, it's different - everyone is fully remote, all the time. And that leads to a lot of new challenges.

As a software engineering coach, my job is to help others learn new technologies as well as new ways of working...and this different reality has presented plenty of learning opportunities that I'm excited to share with you!

1本の矢なら折れるが、3本の矢なら折れない - One arrow may break, but three cannot.

Mob programming as a concept is intriguing, but it also comes with an interesting set of challenges. From environmental issues with keyboard layouts, lighting, noise, time management, and screen size to psychological safety of coding in front of peers, working together in this format presents hurdles for even the most skilled engineer. In this talk, I tackle some of the lessons learned at the Target Dojo in how to make mob programming more safe, comfortable, exciting, and fun. I will also cover a few “pilot programs” currently being developed (including mobbing across individual screens) that provide engineering teams the ability to work together in brand new ways.

Software engineering may be difficult, but fostering a working environment that enables skilled engineers to perform their best can sometimes seem downright impossible. Every day, many engineering teams are battling a messy whirlwind of forces like unmovable deadlines, impostor syndrome, psychological safety issues, personnel/leadership conflicts, fierce technological preferences, and more. With teams more distributed all over the world than ever before, cultural differences can exacerbate many of these difficulties.

As a software engineering coach, my job is to not only introduce new technology to software teams, but to strengthen their working relationships within their organization. Coaches aren’t simply technical instructors. Rather, they are change agents that guide a team towards better outcomes for their project as well as their interactions with one another.

In this presentation, I will discuss tips, tricks, and techniques that technical leaders and managers alike can utilize to better coach engineering teams, including concepts like the definition of empathy (and, more importantly, what doesn't count), the trust-influence relationship model, introducing new technologies in a meaningful and consumable way, and a 5-step process to provide teams confidence to own their new solutions moving forward.

井の中の蛙、大海を知らず。A frog in a well has no knowledge of the great ocean.

As companies grow and evolve, common problems can occur. Often, the larger the company, the larger the problem.

One way many organizations choose to tackle these problems is through the introduction of immersive learning spaces, sometimes known as the "Dojo" concept. Through introduction of experimentation, Agile development, and offerings designed to build stronger teams - as well as application of novel coaching and instructional techniques - immersive learning spaces can improve efficiency and empower teams in brand new ways.

In today’s ever-changing and competitive landscape of online retailers, companies invested heavily into end to end testing practice to ensure the best quality for their product. The seamless shopping experience between mobile and physical store is the universal high bar for success.

Retailers that embraced omni-channel mobile first strategy often build their system top a multi-tenant architecture. In order to make all tenants work in harmony as one unit, across all engineering teams, Test Driven Development (TDD) must be one of the Objective Key Result (OKR). The center piece of that effort is the investment in automated end-to-end testing. During this session, come join David for a in depth look of how Cypress.io enabled dev team incorporate automated testing for both internal web applications, and its public facing e-commerce site.

There are an increasing number of engineering teams adopting React to build their e-commerce solutions, or high performance single page applications for any business sectors.

As the adoption increases, there is also the need to create, and publish reusable react components to share across teams. Come join David and Michael to hear how their web UI/UX engineering team laid the foundation for this effort. They will review the process through which, the core decisions were made. The presentation will discuss the options and considerations for a component library development environment. They will share important lessons learned while exploring the many ways of handling style and themes for reusable components and the tradeoffs. Audience will learn the importance of automated testing for the components created, as well as continuous integration to assure no one breaks the build. Finally, they will share about component publishing, what they had to consider prior to distribution, whether to an internal or public repository for consumers.

井の中の蛙大海を知らず - "A frog in a well does not know the great sea."

Software engineering may be difficult, but fostering a working environment that enables skilled engineers to perform their best can sometimes seem downright impossible. Every day, many engineering teams are battling a messy whirlwind of forces like unmovable deadlines, impostor syndrome, psychological safety issues, personnel/leadership conflicts, fierce technological preferences, and more. With teams more distributed all over the world than ever before, cultural differences can exacerbate many of these difficulties.

As a software engineering coach, my job is to not only introduce new technology to software teams currently looking to transition to DevOps, but to strengthen their working relationships within their organization. Coaches aren’t simply technical instructors. Rather, they are change agents that guide a team towards better outcomes for their project as well as their interactions with one another.

In this presentation, I will discuss tips, tricks, and techniques that technical leaders and managers alike can utilize to better coach engineering teams, including concepts like the definition of empathy (and, more importantly, what doesn't count), the trust-influence relationship model, introducing new technologies in a meaningful and consumable way, and a 5-step process to provide teams confidence to own their new DevOps solutions moving forward.

スピーカーは日本語が分かるから、セッションコンテンツの日本語版もあります。

“小打も積もれば大木を倒す” - Little strokes fell great oaks.

Introducing test-driven development to delivery-focused software development teams provides a unique set of challenges. For example, how to begin the process of deciding what to test? As a Software Engineering Coach tasked with improving software development practices across a large enterprise, I've been hard at work tackling this very problem. The solution I found is simple: describe the requirements, then let automation do most of the work!

Category partitioning (or category partition testing) is a testing methodology based on input/output analysis that emphasizes both coverage and error detection. Combining manual design and automated test generation, the systematic nature of this method takes a lot of the guesswork and anxiety out of deciding how to begin building out a TDD suite for teams starting out.

In this session, I will walk through a sample application of the category partitioning method centered around the development of a simple application, including all of the steps of the method: identifying independently testable features, splitting features into categories, partitioning categories into choices, identifying constraints and boundary conditions, and finally generating a suite of test frames through an automated tool that could be used to begin development using TDD.

スピーカーは日本語が分かるから、セッションコンテンツの日本語版もあります。