Yes, you can deploy every two days


Maria and I spoke at the Agile CE conference about a method of work that we use to help teams deploy every 2-3 days. Here are the slides.

Some impressions immediately after the talk:

  • Corey Haines told me that he uses almost the same method, only in a team of 2
  • “Bucket planning” seemed to catch the attention of a few participants. Basically, the idea is that the capacity is fixed and you should only decide what can fit in the capacity

* Some people were surprised by the idea of not having a Scrum Master but a benevolent dictator. Well, here’s the surprise: this method is not Scrum. The idea of a benevolent dictator is that he’s a thought leader accepted by everyone in the team who can make decisions when there are conflicts. This doesn’t mean that he doesn’t listen to everyone or that he’s making decisions all by himself. Everyone participates, he leads. He also convinces people that they need to do the technical practices and that they need to learn and practice. When I had this role, I left the team after a while, so they and they were able to continue working without this role. So maybe it’s just a way to help people adopt the practices that they need to in the beginning. * Someone commented that speakers talk about teams that use technical practices like pair programming, TDD, refactoring, clean code, when most of the people in the public don’t do that. I think it’s time to understand that developers must learn these techniques, or similar techniques that create the same value, if they want to be professionals.

I believe this method is valuable for its context: small team, engaging product, need for early feedback and I believe that it’s time to think about the things that we do really hard, and to come out with better ways of creating value. This is what agile thinking is about.

UPDATE Some more comments after the open space session:

  • Corey suggested that we name this method “Software development” or “Too slow” because it’s too slow for him, since he deploys every 4-6 hours. Another suggestion was “Extreme Agile”
  • The important thing is to think about how to cut the time. It’s not necessary to try to get to 2-3 days, it’s important to do it better than today, to figure out the techniques that you need to learn to decrease your time to market
  • You may find out at one point that you deploy too quickly for the customer / users to give feedback. You should set your expectations depending on the whole system.
  • I’ve realized that we prioritize the backlog based on business value and knowledge about the feature. If we don’t know enough about it, as valuable as it may be, it’s impossible to move forward.

Add comment Reflections on design, craft and software

A new home for merging ideas about design

It is my strong belief that software design can learn a lot from other design disciplines. I wrote blog posts, a book and did talks on this topic, and it was time to group them all together. These ideas have now a new home: My plan is to add more blog posts there, and to involve other people doing work in this area.