During the last months, I've been working on this article. It shares stories about the software industry in Singapore and my perspective on why it will have to improve a lot in the future. I've written this article because I've frequently have discussions on the subject, but actually do not have any place where I could publish it. Therefore, if you like it, I'd appreciate suggestions on where would be a good place to publish it (other than this blog). You can find the PDF version of the article here.

--------------------

Title: Singaporeans, wake up! Why software is eating your island

The old-world economies, US and Europe, are losing their advantage in 'old' industries such as consumer electronics and manufacturing, yet many don't seem to be bothered. Why? Even after years of outsourcing, US companies are still the frontrunners in the 'new' industries -- the software-centric industries. But Singapore is missing this boat.

A year ago, Marc Andreessen -- the founder of Netscape, a member of the board at HP and an important venture capitalist --  posted an important and wonderful article in the New York Times "Why Software is Eating the World".1 He describes how software is overtaking traditional businesses. The most frequently-stated example of this is the bankruptcy of Borders Bookstore in 2011 while the online bookstore Amazon.com -- a software company -- is still thriving. Closer to home, the biggest computer bookstore in Funan Digital Mall closed its doors the same year. These days, who buys technical books in a physical store?

In traditional companies, the role of software is changing from supporting the business to becoming the core business. These companies need to re-learn their 'new' core business... or else a new start-up software company will learn their 'old' core business and take over their market and they will end up like Borders or the Bookstore in Funan Mall.

In Singapore, this re-learning will be more intense. Why? In general, Singaporeans do not have an interest in learning or understanding software development (yes, there are exceptions). They'd rather be an analyst, salesman, marketeer, or even better... a manager. These jobs have traditionally been important, well-respected and well-paying but... Singaporeans, wake up! The world is changing. A career in management or sales might not be such a great idea in 2012. Careers in software are of increasing importance and you are missing all of it! If this attitude doesn't change then it will lead to mass unemployment and will seriously hit the Singaporean economy. Am I exaggerating? I don't believe so, please let me clarify.

Poor state of software

Software in Singapore is horrible. I find it unbelievable that companies can get away with badly-designed software of poor quality that isn't functional. Examples?

Singapore Air -- I enjoy ranting about Singapore Air as they provide so much to complain about. In 2011 they 'upgraded' their website. Their new website was so bad that I wasn't able to book a ticket online and I eventually changed airline. At that time, Nicholas Ionides, the spokesman for Singapore Air, reported: "As with any major IT project, we do expect teething problems but we expect to be able to iron out these issues in due course."2 No, Nicolas, projects like your website don't have teething problems, it is just shamefully poorly developed. In May 2012, Singapore Air reported an unexpected loss because of "weak travel demand and soaring jet full prices."3 A month later their site is down because it is "currently experiencing technical difficulties."4 Wonder where the weak travel demand comes from?

But perhaps Singapore Air is an exception? Not really...

Singapore Bank 5 #1 -- Our company used to have an account at Singapore Bank #1. We do all our banking via eBanking and, after a year, we changed bank as their eBanking doesn't support recurring payments -- a feature I had always assumed all eBanking systems had. The bank did always assign friendly relationship managers to us... but they seemed to miss the point: We don't need relationship managers, we need a proper eBanking system.

Singapore Bank #2 -- New bank, which does support recurring payments, yeah! We're switching banks again. Why? Their corporate eBanking can not report detailed real-time credit card information. But that's not all. Their credit card summary statements showed the wrong credit information. The bank even charged us late payment fees as we had paid the credit card based on the on-line information -- the wrong information. Their friendly relationship manager told us to use the paper statements instead, which we had always ignored. We seemed to have been the first customer to notice this huge and obvious bug, but after six months they still had not fixed it. To make matters worse, after six months they had conveniently forgotten about it. We're not sure what bank to choose next.

Singapore Stock Exchange -- A couple of months ago, I was in Hong Kong coaching at an international investment bank. I mentioned the sorry state of software development in Singapore and they all nodded in agreement and sighed. "You won't believe the Singapore stock exchange," they told me, "it is an absolute disaster."

There is hope as the government is promoting software development! Then again, how do most of the government web-sites look?

The case of the missing Singaporean developers

I mean no disrespect to construction workers, however it seems to me that Singaporeans view software development as construction work -- the dirty work done by cheap labor, the dirty work they don't want to do themselves. Every now and then I chat with computer science students and they often express the actual programming as a painful phase in their career which they have to go through in order to get promoted to something better. Promoted to project manager or business analyst -- or other jobs which I personally consider to have no future... but more about that later.

There are companies in Singapore who care about the state of their software. These are usually not Singaporean companies. An investment bank in Singapore which we work with trained all their developers in modern agile engineering practices and hardly any of them is Singaporean. Or, a start-up in Singapore of about 40 people with zero Singaporean developers. Recently, I met with a manager of an international embedded systems company in Singapore. He is Singaporean and I mentioned IDA CITREP subsidy for Singaporeans. He laughed and said that he was the only Singaporean in their team. A friend of mine is a CTO of a finance firm and his policy: "Never hire Singaporean developers as they do not know how to develop."

"Software development is unpopular because of the low salary," I'm often told. Therefore companies hire developers from India, Indonesia, Malaysia, Russia, United Kingdom, United States, France, Holland... But UK, US, and France are not 'low-wage' countries, so what is going on here? I asked exactly this question to a CTO of a finance firm and he replied that the good software developers get paid a lot higher salary than sales, marketing or project management. Why? It is easy to find sales people or wannabe managers but finding good developers is really difficult. Perhaps the low developer salary is a myth?

Talking about myths. Now and then I'm told that all software development in Europe and US is outsourced to low-wage countries. This amuses me as I never forgot the discussion I had with a CTO of a Finnish games company where he explained that the only reason for off-shoring work was that he couldn't find developers locally. Salary and the work environment for software development is good, so good in fact, that according to the Wall Street Journal, software engineer is the best job in the US in 2012.6

Yummy, an island

In January, I was in Shanghai and needed additional heating. A friend and I drove to the nearest electronics mall. I found the perfect heater and told the store assistant that I wanted to buy it. She said it was not for sale. Puzzled I looked for a less perfect one but that one was out of stock. I asked my friend what kind of mall this was -- why don't they sell things? He answered most people buy things online, not in malls!

This fundamental shift will also happen in Singapore. Software is becoming part of the core business of organizations and, with that transition, software development is a core skill to have. But in this fast-paced, software-intensive world, the software developers must deeply understand the business they are working in and work directly with users and customers to create the best solutions. The days of software developers who only understand technology and who wait for analysts to specify the work are over. Software developers need to broaden their skill, understand their domain and remove the wasteful handoff of information from analysts.

Related to this shift is the change in management style often called 'Agile'7 where cross-functional teams work directly with users and customers using short iterative feedback cycles. Some management responsibilities, especially project management, are delegated to these self-managing teams so they can respond quickly to the needs of customers. The team members balance between deep specialization and being enough of a generalist to always move the team forward. This delegation to self-managing teams who balance specialization and generalization makes specialized management jobs such as project manager gradually obsolete.

In Singapore, this shift will be tough as it requires cultural change on three different levels. On an organizational level, organizations need to understand software rather than looking at it as a cost centre which is best out-sourced and off-shored. On a management level, management need to empower people and create inspiring places to work rather than the hierarchy and micro-management control that is unfortunately common in Singaporean companies. And on the national level, we need to create a national culture wherein people chose a software development career rather than considering it beneath them.

Currently Singapore is going in the opposite direction. Universities do not promote engineering careers and the recent, stiffer criteria on employment passes8 will make it even harder to find great software developers. I definitively hope this will not lead to companies pulling their development out of Singapore. If it does then that will definitively take a big bite out of Singapore's old-fashioned economy.

------------
1. http://online.wsj.com/article/SB10001424053111903480904576512250915629460.html
2. Reported in Straits Times
3. Reported in Reuters news (9 May)
4. Reported on Singapore Air website
5. Original names are removed for now as that wasn't the point.
6. http://online.wsj.com/article/SB10001424052702303772904577336230132805276.html
7. http://www.forbes.com/sites/stevedenning/2012/04/09/the-best-kept-management-secret-on-the-planet-agile/
8. http://www.straitstimes.com/The-Big-Story/The-Big-Story-3/Story/STIStory_702077.html

"There's always a duck" is a LeanPub book written by Elisabeth Hendrickson (a friend of mine). You can find the book here. Since it is a LeanPub book, I can't review it on Amazon.com therefore I'll just post it on my blog. Is this the gradual end of Amazon.com who gets taken over by internet-age publishing companies? Who knows.

Anyways, There's Always a Duck is a collection of articles and blog posts that Elisabeth has posted over the last, well, 15 years or so. The book is names after the first article with the same name. The book consists of eight named parts with each about 5 articles under it. It is around 170 pages with huge fonts.

It is hard to summarize the book as it really are independent articles which are sometimes 'accidentally' linked together. The articles are Elisabeths observations of her experiences and the lessons she has drawn from it. This could be her daughter telling her that she always sees ducks with which Elisabeth concludes that if you look carefully, you'll see familiar things around. Or the description of "normal coffee" in India with which she concludes that even 'simple' terms such as 'normal' depend a lot of who is saying them and in what context.

Most of her later articles tend to be related to Agile development, whereas her earlier articles tend to be more testing focused. Yet all of the articles have some useful lesson in it. Articles are short and easy to read which makes the book a perfect reading book for short moments in which you have nothing better to do like sitting in the train or waiting in a queue :)

Though I'm probably biased, I did enjoy the book quite a lot. It isn't a wow book that I would recommend to everyone, but it is an enjoyable book full with useful anecdotes which make you laugh and are useful. From that perspective, I would recommend it as a book that you can every now and then pick up and read an article. I'd rate the book probably 4 out of 5 stars, better than "ok" yet not a book that I'll be recommending to everyone.

I do recommend getting this book simply because if it self-published and authors like Elisabeth ought to get more support via their self-published work :)

Today, accidentally, we invented a new term: Dependency Objection :)

We started using dependency objection in design by preventing dependencies so that we don't need to inject them anymore later. Thus prefer to do DO over DI.

Interesting...

PSPI (Potentially Shippable Product Increment) is an important concept in Scrum framework. At the end of sprint, team is supposed to deliver a potentially shippable product increment. The focus of PSPI is on the readiness of the delivery.

MVP (Minimum Viable Product) is a term popularized in lean startup. It's defined as "that version of a new product which allows a team to collect the maximum amount of validated learning about customers with the least effort". The focus of MVP is on maximized learning with least effort.

Their focuses are different, and MVP is often not with production quality. So, the question is, are they compatible?

• PSPI is about transparency

First let us understand more about PSPI, and why Scrum demands that at the end of every sprint. Scrum is based on empirical process control, where transparency, inspection and adaptation are three legs of Scrum foundation. Transparency is absolutely necessary for effective inspection and adaption, while having PSPI at the end of every sprint provides a great deal of that.

There is a companion concept called the Definition of Done. Done defines the extent about how close we are towards being potentially shippable. Unfortunately, many teams are not able to create PSPI in every sprint, because they are not technically capable in doing so. Thus, based on the current technical capability, they define their definition of Done as a subset of what's required for being potential shippable. What's the impact on transparency when we have weak Done? The weaker the Done, the less transparency we have. We may not be able to elicit the full feedback with partially done product increment, and we may have hidden risks left later due to that. 

Release burndown is one way to represent the transparency. It works by measuring velocity based on Done items and deriving the duration from the size and velocity. Notice that those are all defined, estimated and measured based on Done. If we have weak Done, the burndown point is far from the shipping date. Hardening sprints are necessary in those cases to make up for the undone work and get the product eventually shippable. Hardening sprints obscure the transparency.

In short, PSPI plays critical role for getting transparency and making effective inspection and adaptation accordingly.

• Isn't learning creating transparency

Nevertheless, the focus of MVP seems very different than PSPI. It focuses on learning, getting knowledge and reducing risks. Normally, we don't try to reach production quality in MVP, because it often doesn't yield more learning.

Jeff Patton has popularized the distinction between iterative and incremental. In his term, incremental implies "add functionality", while iterative implies "build something, then evaluate whether it'll work for us, then we make changes to it."

For incremental development, PSPI makes much sense, since that gives us the best transparency. While for iterative development, MVP makes more sense. PSPI doesn't help much in creating transparency during product discovery. The extra work to get into PSPI may be wasteful and slow down the iterating. In fact, the increase of transparency comes from the learning. The learning helps us make effective inspection and adaptation, which could be more learning needed or converting MVP to PSPI. As we'd like to capture all work into product backlog in Scrum, a separate item for this elevation is a natural choice. For most product development, the transition from product discovery by iterating to product delivery in increments is common.

Final note

Getting back to the Scrum foundation - transparency, inspection and adaptation. Transparency is the first key, while PSPI is one way to achieve that. Depending on your context, it may or may not be the most effective way. By understanding why Scrum demands PSPI (for transparency), and what other alternatives to achieve transparency are, we incorporate MVP and other techniques while doing the essence of Scrum.

I worked with an organization that adopted Scrum for months. Their traditional release milestone for "content frozen" still kept, and I found that they had assigned all features to teams in sprints on that milestone. I asked, "wouldn't it be change on requirements while you are doing the release?" They answered, "we don't have emergent requirements."

One important characteristic for good product backlog is being emergent. While different markets have different rate of changes, I doubt that some market is so static that there is no emergent requirement at all.

Scrum provides a framework to inspect and adapt. Even though that doing inspection and adaptation inside R&D already helps, lack of emergent requirements prevents us from reaping its full benefit. I'd like to explore this problem and possible leverages from two areas.

1. Disconnection between business and R&D

This disconnection is still one major source for the problem.

• Product Owner from R&D

Product Owner should be business oriented, while we see that R&D oriented Product Owners are still prevalent. Their connection with real customers and markets is weak, accordingly, they lacked the insights and abilities to come up with emergent requirements to increase customer value. The synergy by having business people and R&D people work together is missing.

Product Owner role responds to the need to bring business and R&D together, since that's essential to develop great products. If Product Owner has more R&D background than business background, it may not be a show stopper, but it certainly means that this Product Owner needs to spend significant efforts towards business and customer side.

• Contract game continues

In some organizations, they are able to get Product Owner from business side, e.g. the product managers. While they are made as Product Owner, the mindset of predictive planning and the practice of contract game continues. The most obvious sign is the very existence of milestone for "content frozen" and release commitment. Traditionally, we treat changes as evil, thus, do strict change control. Same mindset continues even though we have adopted Scrum, which provides the mechanism for us to inspect and adapt on sprint basis. Release commitment enforced from business to R&D is a sure sign of low trust and lack of collaboration. All of those hinder the business and R&D to work together and capture emergent requirements.

It is best to stop doing those milestones any more, though you may first work on the possibility of committing later and committing in parts at different time.

• Sprint review

Most of sprint review I see is focused too much on the acceptance by the Product Owner, rather than focusing on how to get valuable feedback from customers and stakeholders so that requirements emerge.

We shall first consider whom to invite to attend the sprint review, besides Scrum team (Product Owner, Scrum Master and team). General principle is to invite the people who would be able to give valuable feedback and help make effective inspection and adaptation. It is great if we can invite real customers into sprint review, if not, consider those who are working closely with customers thus have more insights about what to build. It is unlikely that those people are in R&D, unless we are developing products for R&D people. Think of product managers, marketing and sales people, technical support, etc.

Having the right people helps new requirements emerge, and so does the collaboration process. Having the demo from R&D perspective only makes customers and business people bored. Without good facilitation on the conversation, the valuable comments may just be overlooked.

2. R&D's ability to change

I see interesting dynamic between ability to change and the need for change. They are interdependent.

When you have good technical ability to change with low cost, you are more open to the need for change. That openness creates more need for change, in turn, you have more motivation to improve your technical ability. That's a virtuous cycle.

On the other hand, when you don't have good technical ability, you explicitly or implicitly discourage the need for change. Then, without strong need, you lack the motivation to improve your technical capability to change with low cost. That's a vicious cycle.

It's not rare to hear comments such as "but, our customers don't need release that often, why do we need the ability to have short releases?" Sounds similar to "but, we don't have emergent requirements, why do we need to inspect and adapt?"?

If you are able to find other motivations (e.g. quality, predictability) to improve your technical ability to change, after your ability improves, you will likely see more emergent requirements.

End note

Fred Brooks said, "The hardest part of software development is figuring out what to build." It's suspicious that we don't have emergent requirements. Try to look at the above areas, your emergent requirements may emerge:-)

Singapore Airlines is one of the worlds most respected airlines. They keep winning airline awards. I happened to live in Singapore and therefore it is most easy for me to fly Singaporeair. And, I have to admit, it is one of the better airlines and I especially notice this when I fly other airlines.

A well respected company. Known for its good service. A national company many Singaporeans are proud of. Yet, last week, they made an unbelievable F*** U*. So bad, that I'm seriously considering of starting to fly other airlines. Even though it doesn't relate to their flights but... their website.

Last week, Singaporeair did a sudden deployment of a totally new site. Absolutely no incremental deployments, but what seems to be perhaps years of work, suddenly deployed all at ones. I have heard that the company doing this for Singaporeair is... Accenture! (couldn't find anything on the web). And it is an absolute disaster. At first, I just thought the UI was bad, but no... the whole site is bad... but that's not all. The last days I have not been able to buy tickets anymore, which I assume is the main purpose of the site. Every time I try to buy a ticket, I get "system error". Everything in this deployment smells like a waterfall project gone very bad. But let me dive a bit deeper.

First, this was an all-at-once deployment, whereas it seems it would have been "easy" to do it incrementally. But lets assume that it is done "all-at-once" because of difficult technology changes. Even then, the old-site of Singaporeair was gone! Why would they run that risk and not, instead, have the old and the new site running together at the same time. Even the ISP I used for years (pair.com), they never swapped out their webmail at once, but kept the new site as a beta next to the old site. With a site where, I guess, a large part of your purchases come from, why would a company like Singapore Air run the risk of loosing that income (which they have now)?

All-at-once deployment aside, I'm not a UI expert, but the new UI sucks enormously. Not only make the choice of colors and fonts it hard to read, also it takes me a longer to buy a ticket (the one time I succeeded) because there are en enormous amount of clicks. Also a lot of technology seems off or used wrongly, which is visible by e.g. 1Password not working anymore for payments. Not only did they change their site, but also their booking confirmation emails (WHY!?). They didn't bother to inform tripit.com about that so that all the frequent travelers using both these services are not able to combine them. UI-wise, these things ought to have been discovered with earlier review cycles (sprint reviews) as they seem so obvious. If they would have bothered to take one frequent user of the site and let them use it, it would have been obvious. Why am I so sure? Well, just google Singaporeair and new site and you'll find complains for example on BusinessTraveler such as "Awful is an understatement" or Australian Frequent Flyer Community such as "Gotta say that I hate the new website." I mean, that is obvious and should have been found way earlier in the development. Not sure how this site was developed, but it smells like a pure waterfall.

All that aside, if I could use it, I would be somewhat happy. But if I try booking a (try it!) from "Singapore" to "Salt Lake City" date of departure "August 5", date of return "August 12", I'll get:

Recently, my former NSN colleague, Huang Hongqiang, and me reflected on the lessons learnt from Product Owner perspective during our Agile transformation. We used to work together for one product area with 100+ people, 10+ teams for more than 3 years. He has been the Area Product Owner, who provides the leadership on product, while i was the Area manager, who focused more on enabling environment, supporting teams and developing people. We were accountable for the success of the product area, and together with other areas, for the success of the product and team.

The main learning is summarized with 4 stages. Each stage provides the different focus. They are not strictly sequential, but the focus does switch over time.

Stage 1, get visibility

When your Agile transformation gets started, it is very likely that every team seems busy, but nobody really knows the overall status particularly regarding the work value and priority. As Product Owner, your single most important focus shall be getting the visibility by creating the product backlog. Evaluate legacy product, are they really working? do they incur technical debts? What is the maintenance load? Consider value, be prepared to have surprises, e.g. some teams may have been doing low value work for years.

Stage 2, improve predictability

Chances are, there is still lack of trust between business and R&D. You want to build the trust by improving the predictability, i.e. delivering commitment and managing the expectation. Challenges include dealing with wishful commitment, not knowing velocity or unstable velocity to begin with. The visibility improves the predictability. Moreover, you want to delay making the commitment, negotiate for flexibility, get teams involved into continuous analysis.

Stage 3, deliver value with quality

Velocity depends on the team's capability, which only improves over time. As Product Owner, you should not expect higher velocity soon. Instead, focus on delivering less but valuable features. You want to achieve this by working closely with business side and customers, collaborating with team on why, and splitting features into small ones to identify what's the most valuable minimum. Under any circumstance, you should not sacrifice Definition of Done and quality.

Stage 4, increase productivity

Finally, you help team on increasing productivity. Understand "slower before faster" by planning only 80% of your team's capacity. Work together with team to invest on improving engineer practices and paying back technical debts. Agree with team on feature, including legacy, responsibility so that teams continuously improve the product. Discuss with team how to extend their area so that it matches business needs while sustaining velocity.

Hongqiang and me will give a presentation on this topic in the coming Shanghai Scrum gathering on June 24-25. If you want to learn more details, please join our session:-)