Fernando Cuenca has an excellent blog post, here. He discusses what he learned at Agile 2013.
I will summarize his learnings in my words.
Fernando adds some comments about the cost of implementing the XP practices. To me, these costs seem too high and the benefits are delayed too much. In my experience, at least. But, he is right to say that the costs are significant. Still, the benefits are far more significant!
Hope these ideas help you, your Team, your Customers. You can get a lot better (we all can).
I will summarize his learnings in my words.
- The ultimate question is: how to have a better life for yourself, your Team, and your Customers. And then, specifically at work, using Scrum.
- Measure velocity. And specifically, look for increases in velocity. Otherwise known as: acceleration. Measure velocity in Story Points. But don't become obsessed by a number -- look at the bigger picture.
- Get the user stories 'ready, ready' before the Sprint Planning Meeting. It will increase velocity. In part by reducing churn in the sprint.
- Have a clear DOD. Definition of Done. Being ready, ready will help you get to done, done.
- Do a better Daily Stand-up. Who knew the Daily Scrum was for the Team to self-organize and self-manage? (I am teasing all of us -- not teasing Fernando at all.) I like this formulation: 'what did I complete yesterday that helps the Team achieve our sprint goal?' The Team focus is important.
- Measure Team happiness. (See Jeff Sutherland's Scrum Log.) If they aren't happier, you aren't doing Scrum right.
- Focus on fixing the top impediment. By the ScrumMaster (who is driving it), by the Team, by people outside the Team. Non-trivial work. You have a biggest impediment until you are perfect. And even after you win the Super Bowl, you are not perfect. (20 push-ups for imagining that your Team won the 'Super Bowl of Scrum' when you have never even compared your Team to a 'best in my city' Scrum team.)
- No bugs (use XP practices, etc). Ok, 'no identified bug survives the sprint'. May seem impossible to some of you, but it is not. (Yes, some few bugs will still be identified in production.)
- Clean, well-refactored code base. (use XP practices, etc). Makes it almost easy to change.
- Develop a 'continuous delivery' capability. (By removing impediments over time.) Almost always, this pays tremendous dividends, even if you almost never deploy after each sprint. At least you will be able to decide when to deploy (when you have a Minimum Marketable Feature Set) and then deploy 'instantly'. One reason: The bad news doesn't get better with age.
Fernando adds some comments about the cost of implementing the XP practices. To me, these costs seem too high and the benefits are delayed too much. In my experience, at least. But, he is right to say that the costs are significant. Still, the benefits are far more significant!
Hope these ideas help you, your Team, your Customers. You can get a lot better (we all can).
No comments:
Post a Comment