Less Patterns : Operation Features Later
I called it “Build Less Pattern”. But Alistair Cockburn(@TotherAlistair) said that is grammatically wrong, but “Build Less” as a command is good! So I decided to change the name of the patterns. Now, I call it “Less Patterns”. Alistair named it. Thank you, Alistair! I would like to write some less patterns from this post. It is quite premature. Just an idea. But I believe if I expose these, a lot of cool guys would give me some advices!
If you have some cool patterns, please blog it and let me know! My English twitter account is @sandayuu_en. I believe “Build Less” is one of the most difficult practices on software development. But it is really important for the success of a software development project. This blog post introduces the first pattern. It is called “Operation Features Later”. I learned this pattern from Sonicgarden CEO, Mr.Kuranuki. This pattern works really well and easy to handle it. And I really appreciate for Mr.Harada’s support. He contributes to create these patterns. Operation Features Later When I arrived at Sonicgarden, they and a customer discussed about the scope of a sprint. I observed them because I was really interested in how to negotiate the stories. Sonicgarden's philosophy is made of “Build less”. Actually, They are really good at “Build Less”. The customer looked at a business flow and requested a lot of stories. But it was obvious there was no afford to implement all stories. First of all, Mr. Kuranuki gave them an advice from a business viewpoint. He is famous among entrepreneurs in Japan. He knows a lot about business model. He advised them to remove some stories that have no business value. It seems good stories as one unit of it. But if we see it from the point of view, it was useless. The customer agreed to remove it. It might be an another less pattern. And I was really impressed by the next question. Mr. Kranuki said “Which stories are going to be used as an operation function? E.g. aggregation, data migration etc. If you delete these stories, your customer will never notice it. And if it is really needed, we can operate it manually. Thus we can postpone these stories.” This criteria is quite obvious and easy to understand. The customer quickly picked up some stories and put into a n icebox. I named it “Operation Features Later” pattern. After the session, I asked Mr. Kuranuki about this pattern. He said he always used this pattern. Now I use this pattern several times, it works well, always.