Whole-Team Workshops to Increase Developers' Role in Sprint Planningphilippe.bourgau.net1 ポイント·投稿者 philou·5 年前·0 コメント
Technical agile coaching tips to fight exhaustion from laggardsphilippe.bourgau.net1 ポイント·投稿者 philou·5 年前·0 コメント
How to coach developers to get a chat with their product expertsphilippe.bourgau.net1 ポイント·投稿者 philou·5 年前·0 コメント
Collaboration ideas to make remote pair programming more funphilippe.bourgau.net1 ポイント·投稿者 philou·5 年前·0 コメント
Growth Mindset Coaching: Turn Remote Work Commutes into Team Learningphilippe.bourgau.net1 ポイント·投稿者 philou·5 年前·0 コメント
Pair-programming tips and tricks for coaching a remote teamphilippe.bourgau.net1 ポイント·投稿者 philou·6 年前·0 コメント
How the Samman Method helps to sell technical coaching internally?philippe.bourgau.net1 ポイント·投稿者 philou·6 年前·0 コメント
How to deliver a remote training with code-katas and randori in pairsphilippe.bourgau.net1 ポイント·投稿者 philou·6 年前·0 コメント
How to make your learn TDD for Legacy Code, and love itphilippe.bourgau.net2 ポイント·投稿者 philou·6 年前·0 コメント
How to set up pairing office hours to avoid teammates interruptionsphilippe.bourgau.net1 ポイント·投稿者 philou·6 年前·0 コメント
Long-term benefits of mob programming that make it cost-effectivephilippe.bourgau.net1 ポイント·投稿者 philou·6 年前·0 コメント
Make Testing Legacy Code Viral: Mikado Method and Test Data Buildersphilippe.bourgau.net2 ポイント·投稿者 philou·6 年前·0 コメント
More Event Storming Tips – Part 3 – Anti and Meta Patternsphilippe.bourgau.net2 ポイント·投稿者 philou·6 年前·0 コメント
More Event Storming Tips – Part 2 – Facilitation and Existing Codephilippe.bourgau.net3 ポイント·投稿者 philou·7 年前·0 コメント
More Event Storming Tips – Part 1 – Understanding and Rhythmphilippe.bourgau.net2 ポイント·投稿者 philou·7 年前·0 コメント
philou·9 年前·議論Kent Beck's 3X model (https://www.youtube.com/watch?v=YX2XR73LnRY) relies on the same idea that depending on your context, different principles apply.Transitions remain a tricky point. For example, when a quick and dirty wannabe feature becomes a hit, the practices should follow. What happens to the old code ?
Transitions remain a tricky point. For example, when a quick and dirty wannabe feature becomes a hit, the practices should follow. What happens to the old code ?