英国コーンウォールで開催された第５回‘Agile on the Beach’カンファレンスでは，アジャイルソフトウェアデリバリの著名な実践家たちが，この分野における最先端の新たなトレンドをテーマとしたプレゼンテーションを行った。カンファレンス2日目のおもなメッセージは，アジャイル方法論を段階的に適用することで職場のストレス管理と成功のためのコンディション実現が可能になる，‘自主性(autonomy)，目的(purpose)，熟達(mastery)’を標榜する自己組織化チームが成果と適応性を持った文化を創造する，プログラミングや人々やプロセスを包含する技術的リーダシップが必要である，さらには，人々が‘最高’の状態になれるような条件と機会を生み出すような，‘絶え間なく進化するプラクティスの絶え間なく進化する集合体’で仕事をすることが真のアジャイルには必要である，といったものだ。
カンファレンス第2日は，goAgileパートナのJenni Jepsen氏による，‘Agile Leadership and Teams’と題した基調講演で幕を開けた。ビジネス上の利害関係者を説得してアジャイル方法論のメリットを理解させる最初の目標のために，Jepsen氏はまず，プレッシャ下にある人々の認知能力や情報処理，ストレス管理に関する研究成果を検討した。Jepsen氏の講演で最も印象的だったのは，人々の置かれているストレスレベル，特に，仕事に支配されているのではないという感覚や，問題を解決する上での自主性といったものを管理することの重要性だ。
個人がストレスや，あるいは自身の身体が‘闘争逃走反応(fight or flight)’モードに入る恐れを感じた場合，脳内では‘システム2’思考と長期記憶を担う前頭前野がシャットダウンされる。このような場合，さらなるプレッシャを加えるよりも，チームメンバの支援や激励の方が遥かにに効果的である，とJepsen氏はいう。そのためにはチームの人間関係が柔軟で，適切なパフォーマンスを可能にするようなものでなくてはならない。アジャイル方法論を使うことで，この２つの目標を達成することができる。
基調講演では最後に，組織へのアジャイル方法論の導入が時として困難であることの理由を確認した。変化は斬新さにつながり，それが不確実性を生み出す可能性がある，とJepsen氏は指摘する。人は新たな方法に疑念を抱くものであると同時に，厳格な管理のないアプローチに対しては，当初は戸惑いを覚えるものだ。従ってアジャイル方法論の導入は時間をかけて段階的に実施し，振り返りの時間を十分に確保した上で，その過程で見出された課題やメリットについて議論を重ねることが有用だ。
Jepsen氏の講演に関する詳細は，‘Agile on the Beach’ Webサイト内にある，Tony Edward氏の‘Agile Leadership and Teams’セッションのライブブログに紹介されている。またYouTubeでも，セッションの様子を録画したビデオを見ることができる。
HERE(Nokia関連会社)でアジャイルコーチを務めるRicardo Mestre氏は，‘teams’トラックの分科会セッションの皮切りとして，氏が最近関わった‘Magellan’プロジェクトで学んだ教訓について講演した。Mestre氏によると，40名の社員が参加したこのプロジェクトは，継続的インテグレーションやビルドパイプラインといった，完成度の高いアジャル実践と優れたエンジニアリングプラクティスを備えて開始された。しかし，組織がさらなる生産性向上を強く求めたため，氏は自主性(autonomy)，目的(purpose)，熟達(mastery)を備えた，新たな作業方法をチームに導入するための支援を行ったのだ。
チームに導入された原則は，自己組織型チーム，計測可能でタイムボックス化された(SMART)プロジェクト目標の設定，デリバリプロセス全般の集団的オーナシップ，“すべてがレビュー対象(review don’t specify)”，“完了の明確化(done means done)”，徹底的な検証，といったものだった。 さらに，進行中の作業が包括的戦略に沿っていること，作業予測が最新であることを確認し，達成した成果のレビューを行うために，プロダクトのスタンドアップを週２回実施した。
MagellanプロジェクトからMestre氏が学んだ大きな教訓は次のようなものだ – 新たな作業方法へと移行する場合の(自律的な作業を望まない人々との)文化的衝突は避けられない，KPI(重要業績指標)をチーム全員が参照できるようなダッシュボードの用意が必要である(透過的であることが不可欠)，検証プロセスでは自動化されたレグレッションテストとパフォーマンステストが重要である。さらに，レトロスペクティブの結果によるアクションアイテムの実施時期を，チームのカレンダに確保することが必要だ。さもなくば，問題は手付かずのまま残ることになる。
当日２番目の分科会セッションでは，Thoughtworksのプリンシパルコンサルタントで“Talking with Tech Leads”の著者でもあるPatrick Kua氏が，“The Geek’s Guide to Leading Teams”と題した講演を行った。Kua氏は最初に，参加者に対して，ソフトウェア開発チームにおいて技術的リーダの立場が必要な理由を尋ねた。そして，意見のいくつかについて議論した結果，技術的リーダはチーム内における知識の共有と(適切な)一貫性の維持を支援する存在だという合意に達した。氏はここで，技術的リーダという役割は‘３つのP’，すなわちプログラミング(Programming), 人々(People), プロセス(Process)に分類できるという見解を示した。
プログラミングは技術的リーダの本質的スキルである。構築すべきプロジェクトのコードベースを定期的にチェックして問題の所在を理解し，他の開発チームが直面する課題に共感する能力を持たなくてはならない。技術的リーダには，‘賢さよりも一貫性’を持って，共有するアーキテクチャ的および技術的ビジョンの達成と普及をアシストすることが求められる。
対人的技術(People Skill)もまた，技術的リーダとしてだけでなく，優れたチーム文化を確立し維持する上でも不可欠なスキルである。チームの技術的状態を測る尺度としては，ビルドエラーがエラーのまま残っている時間の長さ，コンフリクト回避の必要度，新たなアイデアが提供される頻度，チームメンバが支援を求めることの容易さといったものが挙げられる。チームの成長を支援することも技術的リーダの重要な責務領域であり，そのために“Strengths Finder 2.0”や“The Difference”，“Growing People”といった書籍は有用なリソースだ，とKua氏は示唆している。
最後のセクションではプロセスを取り上げて，技術的リーダにとって人々に対する作業指示は許容できる業務か，という検討で始まった。示された答は‘時々ならばイエス’というものだ。状況に応じた適切な措置を判断するための支援手段として，氏は状況的リーダシップモデルを提案した。さらに，Tuckmanのグループ開発段階についても議論された。Kua氏はこのモデルについて，チームがモデル上のどの位置にいるかを把握し，それに応じた適切なアクションを識別するという意味では有効なモデルだ，と評価している。技術的リーダには自身のための時間を作り出すことが不可欠だ，そうでなければ単に反応的な行動をすることになる，とKua氏は述べて，自身の講演を結んだ。
MPADのディレクタであるRachel Picken氏は‘ビジネストラック’の第３分会で，“Further Adventure with Agile Communication”と題したプレゼンテーションを行った。講演で提示された中心的なメッセージは，ユーザとの作業を成功させるためには共通理解の構築が不可欠であり，アジャイル方法論を使うための強固な基盤を構築するにはプロジェクト目標の再確認が不可欠である，というものだ。アジャイル方法論に不慣れな産業における作業の長期的予測(とそれに関連する計画)提供の要件には，非常な困難を伴う場合がある。例えば，ストーリやトレンドが目まぐるしく変化する広報活動の領域では，極端に長期的な将来予測の能力が直接的な影響を与えることになるのだ。
Pickens氏は，ユーザとのコラボレーションの機会を欠いたことでアジャイルな作業ができなかった，ある失敗プロジェクトの例を紹介した。ここで学ぶべきは，プロジェクトでは“計画の遵守よりも変化への対応”が重要である，ということだ。新規の顧客に対しては，彼らがアジャイル的な方法で作業可能かどうかを評価するために，‘成熟度ベース’の評価マトリックスを用いるとよい。チームとクライアントが共同でレトロスペクティブを行うことも(困難であることが多いが)重要だ。
閉会の基調講演“Continuous Discovery: The Power of Pure Agile”は，他でもないWoody Zuill氏が行った。氏の講演は，真にアジャイルな方法での作業には“進化し続けるプラクティスの進化し続けるセット”が必要だ，という主張で始まった。氏はオリジナルであるアジャイル宣言の文言に注目して，宣言の元々の意図は，価値を(‘包括的資料よりも動作するソフトウェア’というように)左右の項目で１対１に対応付けて表すことだったはずだ，と指摘した。“左に挙げた項目によって右の項目が損なわれてはならない”のだ。
氏はJohn Gall氏の言を引用しながら話を続けて，単純なソフトウェアシステムがいかに複雑なものに進化してきたか，その過程において，効果のない(しかし一般的な)作業プラクティスがいかに‘継続的無改善サイクル’を導いてきたかを論じた。ソフトウェアシステムの開発においては，真に行うべきことがその実行過程で見出される(“行動が事実を明らかにする”)ことが珍しくない。それゆえに，“認識でき，理解可できて，統合性があり，潜在的価値を持ったもの”を作り上げるというアジャイル的手法のアプローチにはメリットがある。それぞれのタスクに分離独立性があるため，個々にデプロイしてフィードバックを得ることが可能だからだ。
真のリーダシップとは，すべての人が’最高’になる機会，優秀な仕事のできる環境を作り上げ，提供することだと述べて，氏は講演の結論とした。
‘Agile on the Beach’カンファレンスに関する詳細はイベントのWebサイトで，プレゼンテーションのビデオはカンファレンスのYouTubeアカウントで順次，それぞれ公開されている。