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

Posted by Marcus Hammarberg on 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.

If you liked this post ... here's more for you:

Published by Marcus Hammarberg on Last updated