Keep it simple

About Agile, Lean Startup, Product ownership, DevOps and Quality Of Life.

[tsuyoshiushio]

A New Business Model Of Custom Software Development For Agile Development

Presentation (SlideShare)

I gave presentation on 22nd ACM SIGSOFT International Symposium on Foundations of Software Engineering (InnoSWDev@FSE) in Hong Kong.

I talked about a business model of Sonicgarden as a representative of Mr. Kuranuki’s team. Mr. Kuranuki is running his own company Sonicgarden successfully using this business model.

I hadn't been sure if this business model could be effective outside of Japan. After I gave this presentation, now I believe this business model could save loads of small business owners and programmer internationally.

Problems of custom software development

When we try to adopt agile software development for custom software development, we have lots of problems.

1. Requirement development is really difficult for customers 2. Fixed scope leads to too many functions 3. Estimation leads to overestimate as a risk management 4. Fixed scope contract makes it difficult to use agile 5. Nouhin leads to a lot of document.

Let me expand.

For customers, requirement development is really difficult. If they can't, they should hire an outsourcer. It would be expensive.

When you use fixed scope contract, customers would be afraid of missing inevitable functions. Thus they try to include a lot of functions.

Why does estimation lead to overestimate? When you estimate functions, you are likely to add more functions than expected. Because you know the prediction could be difficult. As a risk management, they are likely to estimate it with some buffers.

Nouhin is a ceremony. In Japan, when you finish a fixed scope contract of software development, you need to create detail documentation of the software and give them to the customer with the source code with transferring the ownership. This ceremony requires huge documentation and huge man-hours. In addition, no one refers these documentation.

These five points increase the cost of custom software development service.

It was apparent that if we are to use agile and be effective, we need to change the business model itself. With that idea in mind, Mr. Kuranuki started to construct a new business model.

The points are these three.

1. Monthly subscription 2. No estimates 3. Agreed scope Monthly subscription

 Generally speaking, we use fixed scope and time contract when we outsource custom software using software development company’s service. But it is not suitable for agile development.

That is why a lot of company use time and material contract when they want to use agile development. But we think it is not enough because developers are time restricted during 9 am to 5 pm period. In addition, customers tends to add pressure to the team to produce more. This contract leads to productivity worship syndrome.

The most important thing should be value.

Monthly subscription is the solution we choose for the new business model. It doesn’t require any fixed scope, due date and binding hours. The developers just promise to provide their service like SaaS provider. This service is like a consulting business. Instead of just an advice, they provide not only advice but also development and operation.

Agreed Scope / No velocity / No estimates

Agreed scope

By changing contract, we can change the rule of software industory. In this business model, there is no requirement development. Customers and Developers just have a meeting every week. It takes only 2 hours on average.They talk about not only function of the software but also business itself. e.g. strategy, vision and so on. Like a CTO.The developer decides how much amount of function they implement. In this business model, developers never promise the amount of their time restricted, scope or due date. Developers simply decide the scope of a week. We call this agreed scope.

No velocity

They don’t need velocity. In my opinion, I(Tsuyoshi Ushio) know velocitiy is not for managers nor customers but a development team.Velocity is just a relative number, so the number itself means nothing. But I saw a lot of people are obsessed with it and always care about the number. I know it is ridiculous. You don't need to use velocity if you use monthly subscription contract and agreed scope.

No estimates

They don’t need to estimate as well. A developer is in charge of at least one customer. But if they are a good programmer, they can be in charge of multiple customers. It means their salary raise. If a customer doesn't like their performance, they would terminate the monthly subscription contract. In addition, not fixing time of thier work, developers themselves decide how long they need to work. It is more easy to keep their work-life balance.

Using this business model, Mr. Kuranuki’s Sonicgarden becomes a highly successful company in Japan. Now they have over 30 customers for 3 years.

Future reading

The presentation is just 15 minutes and this blog post is just a brief summary. If you are interested in this business model, a paper is available which describes the model in more detail. You can watch the presentation by the movie.

In addition, you can read the book "Nouhin wo nakuseba umakuiku" as well. Mr. Kuranuki published it which is available only in Japanese currently.

For chairs of an agile or a lean startup conference, I highly recommend you to invite Mr. Kuranuki to your conference and let him a presentation and ask him loads of questions.

If you invite him, you'll never regret!

Any questions?

@kuranuki, @yattom, @zacky1972, @sandayuu_en

[tsuyoshiushio]

Less reading

Now I’m in London for English learning.

I had been suffering from "slow reading” syndrome for a long time. I tried several methods, but nothing worked well.  One day, I tried to apply “chunk reading” technique to read something. I read it in an English learning method book written in Japanese. It is said that if you want to make sense of what you are reading, you recognise sentences by a chunk - word group. For example, You need to recognise a meaning of sentence per a group separated by ‘/'.

She started to explain a chunking method.  She said "Just read stressed words, then you can understand it really quickly. If you read word by word, it takes a lot of time.” And she crossed out some words on an article.

"A father has been accused of killing his daughter by giving her MDMA."

I also tried this strategy, it works magnificently! Now I can read a same article about 3 times faster! In addition, it gains not only reading speed, but also reading comprehension!  

I suppose that word-by-word reading consume a lot of CPU power of my brain and less reading makes slack and fun of reading.  I used to try to read word-by-word as fast as I can, but it didn’t work. Now I have disposed unimportant words, then I’ve got speed and good comprehension - value.   

[tsuyoshiushio]

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. 

[tsuyoshiushio]

Pull Modeling

I’ve been using object oriented modeling like UML for a long time.  When I join in an agile project, I use it every time. On a white board, as a product owner and analysing a project, every time.  As an agile consultant. I suppose a lot of experts think that modelling is really important.  I believe modeling is an essential activity for software development. Not only design but also business modeling. But right now, “Modeling” has some problems. I’m going to explain these points. 1.  Old-fashioned    About 15 years ago, Modeling was a brand new concept for me. But now, It feels like an  old-fashioned idea. But actually it is an essential idea for software development. DDD is one of a good solutions for this problem. 2.  Overwhelmed   A book about modeling has huge volume. But in a real project, we never use full-size modeling process in an agile project or business modeling. It is very hard to read UML specifications for ordinary developers include me. lol   A lot of people try to solve this problem. One of the good answer is the agile modelling.  3.  Difficult to learn   A lot of books written in the modeling era is aiming for big projects. After the agile era, people threw these away.  Maybe, people want to learn a brand new, cool and simple modeling technique that is best fit for software development  in 2014. I try to think some ideas. Why does it seem like overwhelmed?    When I use UML models in an agile project, I never use these in sequential order.  I notice that I use these models in a pull model.  For example, I joined a software project and the project was not organised.  I try to clarify an overview of the project.   In this case, I always start with a mind map. I love astah. It is really good tool, simple, easy to write model , no difficult constraint, working on Mac. Especially, I love it because it includes mind map. It is extremely important for  this style of modelling. I stared with a mind map in the project. Asking them about objectives, stakeholders, problems, strategy and so on. It takes less than 30 minutes. Then I ask them about existence artifacts. A lot of information was on their own brain. I didn’t need detail, but I needed just an overview. Then I started writing UML diagram using UML tools like astah using projector. Pull Modeling  Sometimes, I want to write a domain model. Sometimes not. Sometimes, I need an activity diagram. Sometimes, a state machine, a context model and so on. When I look back this activity, I never create these using a same order like RUP or something.   Which diagram should we use? The answer is it is depend on a situation. Depend on domain of project. How much they have existence artifacts and so on. The point is pull model.  If I need a model, I just write it. I’m discussing  with my stakeholders and visualising it using UML tool and a projector. It is really prompt approach. The Yokyu Kaihatsu approach In Japan, we have been involved in the Yokyu Kaihatsu approach. It is kind like a business analysis approach. But it is really light weight and I love the style of using UML tools for a lot of purpose. It is very good and lightweight approach in the agile era development. But it still has a firm sequential process. It is one of the weak points of the Yokyu Kaihatsu approach. I think the pull model may solve these problem. We should know triggers, when to use these diagram and how. It could be well organised and be really simple to learn. This is just a simple idea, but I’d like to expand this idea and clarify it.

[tsuyoshiushio]

A Pattern Mining Workshop - How to Build Less

Stay less. The more massive an object, the more energy is required to change its direction. - 37 signals, “Getting Real.”  To move quickly while embracing change and still win the game, stay less. Staying less enable you to react and evolve. The first Build Less Pattern mining session was held in AgileRoots 2014 Salt Lake City. Lot of software projects are suffered by "Build Mass" problem.    The word “Build Less” sounds bit wired for English native speakers. “Build Less Pattern” means a pattern catalog for how to remove/prevent to add software functions. The word is mentioned by Getting Real. A lot of people have already known about staying lean. But it’s easier said than done. I’m an agile consultant. I’ve involved a lot of projects. But about 90% project was infected by this disease. But I’ve never known about the solution. This is the reason why I started collecting Build Less Patterns. I’d started to write some patterns, but I was still not sure how to deal with this problem. So, I decided to ask to meet clever people and correct more patterns.   I’d like to share the first Build Less Pattern’s workshop deliverables! Thank you very much for the participants and organizer of Agile Roots.  This is my presentation. It includes some patterns.

Build Less Patterns AgileRoots 2014 from Tsuyoshi Ushio

This is a mind map about the discussion powered by astah.

You can see the detail of this mind map.

This time, the mining had been done by following step 1. Detect problems related Build Mass 2. What causes the problems? 3. Any solutions? The participants were great. I’ve learned about a lot of insight about Build Less. Analyzing this discussion, as Team C mentioned, almost all problems are emotional reason not logical reason. This is one of the reasons why keeping Build Less is so difficult. About the solutions, I was impressed these opinions. - Ask more questions - Establish trust - Education an agile methods - “Try to see” prove it before investing too much - No fear - Learn to say no - Build Learn Measure cycle - Enable profiler in production for initial product release In my experience, “Ikemen” was the most effective to prevent Build Mass. I'm going to get feedback on actual projects using this new knowledge from you guys!  (About Ikemen, you can see the pattern in my presentation.)

And I've learned a lot of build less patterns from SonicGarden that has a really impressive business model.

Next time, I’d like to have other sessions on the other countries. Both in the eastern culture and western culture. Like Japan, Britain, Vietnam and so on. 

[tsuyoshiushio]

No Delivery, No Due Date, No Fixed Scope

This is a slogan, the Sonicgarden company uses to describe their business model.

Sonicgarden is a custom software development company in Japan. How can a custom-software development company survive without delivery?

Here's what I found during interviews with CEO, their workers and their customers.

The key point is ’No delivery’. It means ‘Do not transfer ownership of the software’.

No Delivery

When a customer orders custom-made software, one will usually own the software after the software is done. But at Sonicgarden, the developer keeps the ownership. Ceremonies cost a lot, when you deliver the software. e.g., documentation, communication with operation engineers and acceptance test. This kind of delivery requires fixed-scope contract. It also costs a lot. Instead of delivering, Sonicgarden would operate and maintain the software for the customer. They provide custom-made software as a service.

Is software ownership important to a customer? Is it valueable? If not, you can reduce the cost of these.

No Due Date and No Fixed Scope  The Sonicgarden never promises the due date. It causes overwork and lowers quality of software. They neither promise the fixed scope even within a sprint. In 37 signal’s book ‘Getting Real P19’. it is said 

Do less than your competitors to beat them. Solve the simple problems and leave the hairy, difficult, nasty problem to everyone else. Instead of one upping, try one-downing.    :  less means:    Less features    Less options/references   : 

'Build Less' is the key concept to create valuable software. No due date and no fixed-scope strategy prevents ‘build more’.

Customer Satisfaction

How can you satisfy your customer with this business model? Most of their customers are startups. They are too busy with their business model. It is almost impossible for people without programming experience to find and hire good programmers.

Sonicgarden is a good resource for them like skillfull programmers on demand. Sonicgarden only hires skillful programmers. CEO said, “At first, some customers feel very nervous, because we never promise due date, fixed scope and so on”.

To solve this problem, the company created a trial period. A customer can evaluate our performance. They use a subscription model with monthly payments. Every customer can stop using the service anytime.

Win-Win-Win relationship

No Delivery, No Due Date, No Fixed Scope leads to satisfaction of all stakeholders.

Employees(programmers) : stay professional , good salary, freedom to choose time and location to work.

They don’t need to commit ‘time’ and ‘scope’. They should commit to ‘Customer satisfaction’. If a programmer could handle multiple clients, the company would pay more. In addition, Sonicgarden has only one role except for CEO---Programmers. There is no manager. Their salay is best-in-class in Japan. About the freedom, I’m going to write on the next blog post.

Employer (CEO) : keep talented programmer, stable profit, sustainability

Programmers are highly motivated because of the benefits and they stay in the company. Profit is stable because of the monthly subscription model. This business model doesn’t require any hardwork because of their 'No Delivery, No Due Date, No Fixed Scope’ strategy. It requires talented programmers, but it does not require too much overtime.

Customers : I mentioned these, before.

Conclusion

No Delivery, No Due Date, No Fixed Scope strategy makes it possible. Next steps 

I’m really interested in their business model. I’m going to write more about this topic.