Singaporeans, wake up! Why software is eating your island
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.
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.
Book Review: There's always a duck
"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 :)
Prefer to do DO over DI
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.
When PSPI does not apply
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.
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.
Take the problem to team
Self-organizing team is an essential element in Scrum. ScrumMaster has the responsibility to help team become self-organizing. Agile coaches often give the suggestion that you should take the problem to team. While this is a good suggestion, it is too much simplified thus not used effectively in practice. I'd like to elaborate the key aspects and ScrumMaster's role in this approach.
It is too often for us to quickly jump into solutions, while it is much more effective to sell the problem than to sell the solution. Slow down to first define the problem. At which boundary should the problem be defined? That is the same boundary you want to enable team's self-organizing. Why does the problem matter to the team? Make the problem clearly seen by the team.
When taking the Scrum context, it is the team who is self-organizing. That's the target we bring the problem to. However, it's beyond that if we think of self-organizing as a different thinking paradigm than command and control. What if the problem relates to two teams? Then "the team" is two teams combined. Therefore, it's really the group of people who should self organize to solve the problem.
The problem and the team are coupled. Let me give you one example from my recent coaching experience. The organization was fighting for getting the release out. The overall situation was challenging. The number of bugs found in system testing, which is still not part of their Scrum team's definition of Done, was high, and system testing was still in progress. Different Scrum teams were working separately to fix bugs, and system testing team was executing test cases according to the plan. I observed that those teams, Scrum teams and system testing team, did not sufficiently work together. Only few people had the idea about where the release was heading. The problem in this situation was the challenge to get release out, while all teams were the people who should work together to face this challenge.
After you define the problem and find the team to work on it, the next step is to enable them to work together. It could be as easy as sending out an invitation. Or you have to first get their buy-in for the problem and the need to collaborate with others in solving the problem. It is worth the time to gradually build the shared understanding and agreement about the problem among the people, before taking it to them for solutions.
- Coaching for depth and breadth
During the whole process, ScrumMaster plays a coaching role. In the beginning, you may see the problem, define it and bring it to the team. Gradually, you coach more people in seeing and defining the problems by themselves. When they start to collaborate, the greatness of the solutions still depends on their capability in problem solving. You coach them in analyzing root causes and designing experiments to verify. There are two main focuses in the coaching - understand the problem within the broader system, and analyze the deeper causes. PDCA, systems thinking, root cause analysis techniques, even scientific method are the great sources of learning.
Self-organizing is not only a team element, but also at the organizational level. Therefore, the approach is actually not only for ScrumMasters, but also for managers in Agile organization. Yes, managers as coaches!
We don't have emergent requirements
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 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.
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.
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.
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:-)
Product Owner is a new role
It is a well-known but still common mistake that many organizations during their Scrum transformation try to map their existing roles such as project managers into Scrum Master role. Recently, i notice that same happens to PO role as well. Not realizing that PO is a new role is as bad as not realizing that SM is a new role. Let's elaborate why.
Starting from PO's responsibility. Here's PO's role definition from Scrum source.
- Should have a vision for the product.
- Defines the features of the product, decides on release date and content.
- Is responsible for the profitability of the product (ROI).
- Prioritizes features according to market value.
- Can change features and priority every sprint.
- Accepts or rejects work results.
The keyword in the above list is ROI, others are necessary but more as means to great product and maximized ROI. When thinking of who shall be PO, I believe that passion for product is the first consideration, since that is the foundation.
A natural but undesired approach to find PO during Scrum transformation is trying to map the existing role to PO role. Let's look at a few common cases of mapping.
Mapping System Engineer (Architect/Business Analyst)
System engineer is a typical role in telecom industry. It is close to a combination of Business Analyst and Architect, working on both requirement analysis and architecture design. The most appealing reason for them to take on PO role is that they have been working on requirements, while PO clarifies requirements with team too. The close relationship with customers makes it an advantage for them to be customer representative. They may innovate on some product aspects, though it may lack the big context.
However, there are drawbacks on this mapping. System engineers are often technology savvy. Even when they work with customers, they tend to push technology solutions, rather than truly listen to customers and understand their problems first. They traditionally care less about ROI, which makes them perfect the system more than necessarily, without creating more value for customers and realizing the cost effect. PO leads release planning and management, while it has traditionally been program/project manager's responsibility. Few system engineers already know how to do that. In waterfall mode, system engineers are usually located in a single functional team, and they communicate via documentation. Chances are, they continue by writing user stories and handing over to team, which breaks the collaboration spirit in Agile development.
Mapping Program/Project Manager
Program/Project manager already does release management, which makes them good candidate for PO in this regard. They normally have better sense of ROI than system engineers. Their skills on risk management helps them manage the release in more predictable way.
However, there are other hurdles to overcome for them. Traditional project manager is control focused. Many of them are good at command and control type of management, while PO works with self-organizing team. PO looks at the unit of PBI, sprint and team, rather than task, day and individual. Project managers need to fight with the tendency of micro-management in order to effectively work with teams. Though project managers manage releases, they focus more on execution, while PO requires the product leadership based on great understanding on customers and constant product innovation through releases.
Mapping Product Manager
Product managers are great source for PO. They are responsible for the profitability of the product and ROI. They work closely with customers, and execute the product leadership by managing the product roadmap and releases.
The major problem for them is the traditional contract game between product management and R&D. They treat release as one unit, set contract in the beginning of the release with R&D, then, go away for future releases. While for PO, the constant collaboration with R&D team and making ROI decisions on sprint basis is the key to reap the benefit of Agile development.
If we look at the main themes appearing in PO role - ROI, product leadership, collaborate with team, release management, really, no existing role in the traditional organization does all of these. PO is a new role! It will certainly lead to problems, if we try to map the existing role to PO role. Telling people that you are PO from now on, while they keep doing what they used to do, does not make them PO.
On the other hand, people with any of the above background may become PO, with certain qualities and skills, as well as the realization that they need to transition to a new role. I have encountered Scrum transformation in several organizations, during which they introduced PO as new role and selected people with different background to fill it. It worked pretty well.
Manager as ScrumMaster
Recently, while i coach a product development organization on Scrum, i notice that they have made all former team leaders as ScrumMasters. Though this arrangement itself may not be a problem, the reason behind that decision certainly concerns me.
ScrumMaster has challenge on leading the team, because team does not listen to what ScrumMaster says, thus ScrumMaster is not able to influence the team forward. As a solution, it grants ScrumMaster with positional power by making team leaders as ScrumMasters. What ensues is that ScrumMasters make use of positional power to get things done. Since it works temporarily, they lose the priority to develop leadership, which is the fundamental solution for their challenge. With the continuing weak leadership, they tend to rely more on positional power. It creates an addition loop.
This is the typical "Shifting the burden" situation in systems thinking.
Where do we leverage in this situation?
- Understand the dynamic as you are reading this:-)
- Leave the fundamental solution open, and explore with relevant people together for alternative solutions for the challenges on leading team, other than using positional power.
- Articulate the long-term goal on how to lead Scrum team and what kind of leadership we need.
- Break the dependency on positional power, either removing it, or practicing not to use it with the help from your mentor or coach.
With the above said, i am a proponent to create the consistency between Manager and ScrumMasters for sustaining the change. I have ever promoted great ScrumMasters to managers and they took dual roles. However, it had different reasons and came with different evolution paths. Read more from We're All in This Together
, or attend my "Manager as ScrumMaster" session
in Agile 2011 conference, where we would explore this topic further.
Waterfall strikes again? -> Singaporeair site s*cks
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:
A system error has occurred. Please try again.
I tried it again and again the whole week. I reported a bug even. But no luck, it seems to not be possible anymore to book a ticket with the new site. This is truly unbelievable, how could a respected company such as Singapore Air allow to deploy a website which is SO BUGGY that even the basic functionality which is the main revenue stream for the company... does not work!
This was reported in the local newspaper: Straights Times in their article "Bumpy start foe SIA's new website". Didn't read the whole article (don't want to subscribe to straights times) but the most amazing part of the preview is the responds from Singaporeair Spokesman Nicholas Ionides:
'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. We will
closely monitor the website's performance, and make adjustments where
So, deploying an all-at-once, unusable, buggy and slow website in 2011 is *still* expected? I do not know where Nicholas has been the last 10 years, but I wouldn't expect it and find it truly shameful.
Insights for PO during Agile transformation
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:-)