Saturday, October 26, 2013

Transitional Patterns

Transitional patterns are those that are usually just execute once to change the condition. In team formation, it plays an important part.

Following are 2 transitional patterns:
1. "Sakura" pattern: Most people don't want to be the first one. They're looking over their shoulders to see if there is somebody else doing it. "Sakura" pattern is to appoint somebody to act to be the first one to do something so others will follow.

2. Vague decoy pattern: When there are 2 teams which should be combined to form one team but they don't want to communicate with each other too much, information that one of the team needs is made vague on purpose so they are required to communicate to get the information.

Paper:
http://sourceforge.jp/projects/oss-ja-jpn/downloads/59755/Agile_2013_20130507.pdf/

Slide:
http://sourceforge.jp/projects/oss-ja-jpn/downloads/59755/Adapting_Agile_Methodology_to_Overcome_Social_Differences_20130802.pdf/

Wednesday, October 9, 2013

DevSales - Developers and Sales uniting together

DevOps are allowing us to build and deploy faster, but are our sales really going up? Making new features available faster may help increase sales if the service already has succeeded somewhat, but what about for startups? What about for all of us who have toiled away development software without seeing none of them really hit?

What startups and most of us need is not a faster way to develop and deploy but a more surer way of making sales on what we develop. In comes DevSales - developers and sales working together to create a software that sales would more easily be able to sales to customers.

Nexlink was a company trying to find a way to make their software sale more. Most companies tries to find features that users would like more - develop for the users is the common concept. However, if you've actually been in a software business, you'll know that this isn't entirely true; selling a software is not just about development, you'll need a good marketing and sales teams.

In most companies, product planning and development teams just develop some software and tell sales to go out and sell. It's up to each sales person to think up on a way to sell it. In most cases, the only motivational reward is sales incentive from a sale.

What if sales team took part in product planning and development? What if sales people were able to provide input to from the beginning so product specification is not solely based on what end-users want but on what sales people wanted so they will able more able to make sales?

DevSales is about uniting development teams and sales teams so sales teams would be more motivated to sell the product. In the end, it's people who actually sell to other people. Focus on people over product - that's what agile is all about.

The result? Nexlink were able to sell to over 100 companies before the product was actually developed.