#10: ASD開発について分かった気になっていたことを観測し挫折

kinocoboy
·

ScrumFestNiigata2024 へ参加

本日、スクラムフェス新潟2024に参加してきた。

今自分が頑張って会得したASD開発はちょっと自信のある武器になっていたので、胸を張って取り組みを話すつもりだった。

そんなときにASD開発を実際に取り組んでいる方とお話する機会を得たので、ウキウキで話していた。

しかしながら、その方の取り扱っているASD開発の姿勢や理解度、解釈が私とはまるで雲泥の差だった。

ASD開発の深さを思い知る

ASD開発では、複雑な動き = 簡単なルール × 豊かな人間関係 という方程式で生み出す力を行使して闘うスタイルだ。

私は確かにその観点については理解できていたし、間違っていないことも分かったのだが、問題はそこから。

ASD開発では、タイムボックス・状態・関わる「仕事」の全容見える化 をすることが最低限のルールとして求められている。

私もProject Data Sheet という形だったり、チーム日報という形で、weekly, dailyのタイムボックスを意識した、かかわっている「案件・プロジェクト」の状態はすべて見える化していた。

しかし、その現状に甘んじる形でそこから先の進化を怠っていたことを思い知る。

関わる「仕事」の全容の見える化の浅さ

自分たちの関わる仕事がなぜ「案件」だけだと思い込んでいたのだろうか。。

自分たちを取り巻く環境とのコミュニケーションだったり、いろいろな作用に対するアクションもすべからく「仕事」であるはずだ。

物理学における仕事の定義でも、何か自分たちがベクトルを持った力をかけると発生する。

これらはフロントだったり、バックオフィス、関係するステークホルダーとのやり取りでもベクトルは少なからず発生するし、事実している。

それを私はなんとなく日々を過ごし、見落としていたことに気づかされた。

状態に対する解像度

これもそうだ。

関わる仕事の幅の解釈を改めると、観測可能な状態の数もかなり増える。

その状態を見える化し、どこに投資的活動を進めるのかを学習したり、思案したり、協調することはできるはずだ。

でもそれに気づくことができず、見落としていた。

タイムボックスの応用力

これもそう。

今Weekly, Daily のタイムボックスを意識して動いているが、その2つで満足していたことに気づかされた。

なぜ、Monthly や 2week, 2day などの細かい調整を試みなかったのだろうか。

全く恥ずかしい。

豊かな人間関係への深度の違い

特に恥ずかしかったのはここだ。

豊かな人間関係をしっかりと形成するために、Good & New という方法を使っているが、そのGood & New の進化を考えることを怠っていた。

豊かな人間関係こそ今のチームの強みだと思っていたのに、その刃をより研ぐことを考えていなかったことが、何よりもあほだった。

より深い人間関係の醸成を進める方法として、倫理観の共有をしながら進めることで、さらなる発展をもたらすことを教えてもらうことができた。

ASD開発のことなんもわかってなかった

なーにが、No.1 Adaptive Software Developer を目指すだよー。

まだスタートラインに立ったばかりじゃないかー。

すっごい恥ずかしい。

でも恥ずかしいってことは、自分をぶち壊すチャンスがあるってこと。

いい挫折をしたと思う。

ここから本物になってやる。

@kinocoboy
挫折するたびに記事を書きます。 2024年は100回挫折することを目標にした。