We'll talk about Mob Programming and related topics.

Currently in our environment of 27 developers we have no manual tests for the software to deploy to production. We practice continuous integration, and continuous delivery. All infrastructure is written as code. Bugs and defects are top priority with no bugs most of the time. Team members treat each other with psychological safety. We have a 2-hour value stream for our cloud based IOT product. This means a customer can receive changes to the software within 2 hours of the start of the feature.

How did we get to this point? By working collaboratively and practicing Mob DevOps and Mob Programming! In this session we will review the status of the team and how you can iterate toward a similar environment.

The best organizational changes in my career have happened as a result of emergencies. Support for the process of experimentation only seems to become enabled whenever the status quo has completely broken down. In those moments of crisis rebuilding with better has been possible, but why do we wait? In this talk I share our experiences with experimentation at Hunter and encourage you to develop a culture of continuous improvement and continuous experimentation that will get you to where you want to be without having to be in a crisis mode.

私にとっての過去最高の組織的変化は、緊急事態の結果、起こりました。ふつう、仕事上で実験できるのは、今のやり方がうまくいかないときです。危機的状況においては、抜本的な再建が可能です。しかし、指を加えて危機を待つ必要があるのでしょうか？本講演では、ハンター社が行った実験について話します。そして、継続的改善と継続的実験の文化を発展させて、危機的状況に陥ることなく、望ましい状態に進むことをお勧めします。

Today I am the director of a new software development department and we continue to utilize Mob Programming as well as many other practices. This presentation is about my journey through software development and specifically the experiences I have had with the process of software estimation. We are currently a department of 27 with 6 full time mobs; each team does not estimate software but instead practices pure Kanban and delivers vertical slices of software daily. Hunter is not the first place I had dropped the practice of software estimation for a project. Back in 2007 I was working in an Environmental Chemistry and Military Contracting organization that had a more traditional waterfall environment. During that time, we created a Gantt chart of how each project would go until one day there was an emergency that prompted us to do things slightly differently. I have come a long way and experienced many iterative steps through my software development journey. Let’s start with where we are today and work our way back discussing practices and insights we discovered on the way.

現在、私は新しいソフトウェア開発部門のディレクター(責任者)を務めています。私たちはモブプログラミングと他の多くのプラクティスを継続的に使っています。本講演では、ソフトウェア開発を通した私の旅、そして特にソフトウェア見積りのプロセスで経験したことについて話します。私たちの部署では、27人が6つのモブで終日作業しています。各チームはソフトウェアを見積もるのではなく、純粋なKanbanを実践し、ソフトウェアの垂直スライスを毎日提供しています。私がプロジェクトのソフトウェア見積もりを廃止したのは、ハンター社が初めてではありません。2007年にわたしがいた環境化学と民間軍事の組織は、もっと伝統的なウォーターフォールの現場でした。わたしたちがその時作ったのは、やり方を少し変えざるをえない事態が起きない限りはプロジェクトの先行きを見通せる、といったガントチャートでした。私はソフトウェア開発の長い旅を通じて、多くの実験を繰り返してきました。私たちの現在の状況からスタートし、どんなプラクティスを議論し、どんな発見をしてきたのかを話していきます。