ÖreDev day 4 – Why your agile adoption fails with Dan North

· November 5, 2009

This became so much and was so good that I publish it as a separate post.

After pretty disappointing morning I’m hoping that Dan North will bring things back to great – as most of the day was yesterday.

Dan promised yesterday that he will bash on Scrum a lot in this talk… And at the same time as this there is a talk on Entity Framework 2.0. With Ayende and Scott Bellware in the audience…

OK – our hall is filling up. Dan is smiling. Could be fun. Here are some quotes:

  • A manager in a crappy system with a certificate is still a manager in a crappy system
  • Certified$crumMa$ter :)
  • Check out the Satir change model to understand peoples reluctance to change
  • Think of the different stages of the Dreyfus model
  • “75% of uncoached Scrum projects will fail” – Ken Schweiber
  • Get a build/continuous integration! Because flushing out the problems around that process flesh out a lot of problems
  • Automate tests! Introduce assumptions test to test legacy code. Assumptions test is a way to document your assumptions on the legacy code.
  • Understand Deliberate Discovery around the domain, the architecture and the people.
  • Rolling wave planning – only break the imminent stories to details.
  • Get good a writing stories; break features into stories, have them concisely small and then each story size is 1 story. Here he made a reference to “A slackers guide on project tracking”
  • WaterScrum – your sprint are too long Which gets you all the downsides of both Agile and Waterfall…
  • Go to one week sprints. Identify what hurts and fix it! Plan –> Do –> Check –> Act
  • “I love failing. Its fun and is a great opportunity to learn”
  • Spent money is spent (on investment in tooling/processes) – instead think of the impact on effectiveness.
  • Build trust with the business – demonstrate and celebrate success, demonstrate transparency
  • Remember to get the “What’s in it for me!” to all parts of your value chain; operations, test, business, corporate and developers.
  • Projects (and their management) will not pay for change… “Not on my budget!”. Solve this by getting the project management responsible for the system lifecycle and make small changes frequently
  • Introduce a strategic change pot of money that transcends projects
  • On architects in Ivory towers: “I don’t write code anymore – Don’t you see my long white beard?” :D
  • Get the architect into the teams as consultants. Reward them for sharing knowledge.
  • Stewart leadership – leadership by getting coffee.
  • Integrate tester into the team and invest in automated testing.
  • Systematic change requires systemically change
  • “A bad system will beat a good person every time.” – Edward Deming

I’ve run into many of these problems and thought hard on much of the solutions but this was so crisp and good.

Twitter, Facebook