Remembering Tang Ben

I'm interrupting the normal IT stuff in this blog to remember my father, Tang Ben, who unexpectedly passed away last September. I'm doing this because some of his grandkids never got to meet and know how kind, funny, and inventive Lolo Ben was.

Tang Ben knew how to cook. He had several killer dishes in his repertoire, but my favorite (my wife's too), was his asadong manuk. Asadong manuk was reserved for special days -- fiestas and birthdays. He would marinate the chicken in toyo and kalamunding for a day. Then, the chicken would go through an elaborate process of sauteeing and braising and frying. 

Whenever he served it, the dish never lasted long on the table. So he would set aside a half-chicken or more for me and Data. 

Tang Ben said he learned to cook when he worked in his aunts' carenderia. I think what really distinguished his cooking style was his inventiveness. He would experiment a lot -- sometimes with undesirable results. We'd be honest with him when this happened, and he always took it in stride. His strength was learning from his experiments and doing better every time.

We used to have long lunches and dinner, with the elders lingering at the table, telling all sorts of stories. "Peace time" stories were a hodge-podge of prewar and, confusingly, war stories. One of the favorite recurring stories then was about the old toilets, which were elevated outhouses with a hole on the floor and a long stick. The stick's purpose was to push away the pig who would wait downstairs for your number 2 (gross!).  

When Tang Ben was going to school at Calulut as a kid, so he told, whenever it would rain, he had no other place to seek shelter so he would crawl into one of the open niches in the cemetery along the way.  Tang Ben used this story to explain why he was sensitive to spirits (and he had firsthand ghost stories to tell!).

All lunches and dinners would always have a round of jokes or real-life funny stories. But those are for future blog entries.

One of my earliest memories as a child were of him using a trick to make me go to bed. He would lift a small part of the kulambo, making it look like a tent, and would tell me, "Camping! Camping! Quick!" And I would rush to bed, crawling inside the hole.

Project Delta: web-based but standalone app

The vision for Project Delta (mentioned in this previous blog entry) is that it will be used by physicians who are also digital nomads (ie, sometimes they're working online, sometimes they're not). This means:

• Delta needs to act as a standalone app when the doctor is disconnected from the network.
• When there is a network connection, Delta acts as a web application that syncs its data over the network.

It's also important to state here that we decided this app would be built on RoR (Ruby on Rails). We want to benefit from the RoR's strength for supporting rapid and flexible development. But RoR brings one disadvantage -- it's still a pain to install on Windows (and some of our intended users may be Windows users).

Mulling these over, I formed early ideas about the technical solution. But I am aware that others are much better and more experienced than me on this one, so I asked my panel of technical advisors about this.

Here's the summary, which is good enough to go on:

• For a quick installer for Windows, try RailsFTW by Brian Bibat. 
• Stack Overflow discussion thread about distributing RoR apps as standalone apps.
• Essential tools for Mac Ruby developers is self-explanatory. Some of the tools are not that important in my opinion, but it's a good list to start.

If you know a good solution for our technical issues and requirements, do send me a comment. Will highly appreciate it. 

5 Important benefits of Scrum and Agile

I have been helping a small-sized government agency (let's call it Agency Pi) to improve its IT services. Management wanted the IT section to be more responsive to the information needs of the agency, which feeds into policy formulation which in turn helps create more intelligent decisions. That of course is the vision.

The IT section was not built for that new vision, so I was tapped to help make the transition. I decided to introduce Scrum and Agile software development methodologies to the organization. Note that we did not just introduce Scrum to the IT section, but to the whole organization. The way we introduced Scrum is a separate story in itself, so I'll leave this for another blog entry.

For this blog entry, I want to write about the benefits Agency Pi gained from this change effort. We could sum them up to the following:

1. More customer-centered development. 

Scrum puts the customer (represented by the Product Owner) in the center of development. Programmers often snubs customers, treating them as clueless clients. The important change here was to convince everyone that the Product Owner (PO) should have more involvement and a strong voice in defining the product, the development timeline and the team priorities. 

This is contradictory to traditional project management principles, where it's mostly the PM who decides on the schedule and priorities (in "consultation" with the customer).

2. Improved customer involvement in product development. 

The IT section catered to internal customers, usually heads of departments in Agency Pi who were dissatisfied at the inflexibility of the IT staff in responding to change requests. In my observations of the organization, it became obvious that Pi had what I call managementitis.

Managementitis assumes that software developers can easily predict what the customers want and could build a solution with minimal customer collaboration. Managementitis is a flavor of delegation by abdication. That is, after giving instructions, customers can forget about the project and come back at deadline time to see the magical software that the team developed without customer involvement.

To change this mindset, we enforce the requirement that customers should assign a "full-time" product owner (PO) in the project. This PO will make important decisions that contribute to the design of the software. We also require the customers to attend the regular product reviews (we made some mistakes here, but that's for another blog) so there are no surprises.

3. Team mindset that embraces change. 

A more difficult challenge was convincing the programmers to welcome changes requested by customers. The developers are used to the waterfall approach -- hammer out all the details in the design phase, get signoff, and build the software. 

In my experience, this way of building software is inflexible, resulting to programmers who stop listening to customer change requests, and high customer dissatisfaction. I still see this tendency in the programmers, but when I see it resurfacing, I just repeat the message that "Let's accept the reality that our customers will always want to change a feature especially because what we're creating here is new to most of us."

4. More balanced leverage for negotiation between customers and developers. 

The old mindset at Agency Pi promoted an adversarial relationship between customer and developer. For example, customers tended to demand unrealistic deadlines and then wanted programmers to commit and be accountable for the results. Sample dialogue: 

Manager/customer: "I want this very important database system to support our Program Such-and-Such. I don't know what its features are yet, but I need it next week. You need to bear in mind that since we don't know its features, you should be prepared for changing requirements. But I still need it next week." 

Programmer: "Uhm, okay. (Scratching head and wanting to jump out of window.)

You could see where the dialogue above would be headed (hint: "Hell."). And this often happened at Agency Pi. Using Scrum, we started advocating for more customer involvement. More customer involvement through the PO meant giving the PO more insight into the complexity of development. We made the customers see that development was about managing time, effort, cost and quality. Managing time is of course an illusion -- so we simply adjust cost, effort and quality based on the time we have. This is a key paradigm shift that customers and even developers need to understand in Scrum.

To do this, we repeated key messages like "We are now more open to change requests, but please recognize that these changes impact on time and effort" and "We will respond to that request, by adding it to the next sprint -- we assume that you want this prioritized?" or variations of these messages. Many developers hate to repeat themselves. But when you're dealing with deeply embedded organizational behavior, repetition helps.

Moreover, the Scrum approach gives the power of making product decisions back to the customer/PO. This often produces amazing results. Customers are more conscientious in making change requests and are more willing to bargain one feature for a more important change request.   

5. Improved customer satisfaction.

Of course, doing all of the above have resulted to better relationships with the customers, and a better grasp of the internal development processes that are happening on the side of the programmers and on the side of customers. 

There is now also more dialog happening in the development team, which by the way now includes the customer as part of its members. The programmers feel more empowered because it is clear to them that their participation in decisions is only up to the technical aspect. Issues on prioritization and scheduling are left for the PO to decide.

7 things I like about School for Startups (Book Review)

As an entrepreneur and a teacher about entrepreneurship and business, I've read many books about  starting a business. School for Startups stands out among the rest of them. What I like about the book:

1. It emphasizes taking action immediately on your business ideas.
2. The authors promote the contrarian beliefs that (a) you don't need to take big risks to be an entrepreneur, (b) you don't need lots of money to start a business, (c) you don't need a big or cool or original idea to start a successful business. Based on my experience, I agree on all of these.
3. The book contains many real-life examples of people who started their own businesses with very little capital and using simple, even copied, business ideas. 
4. These examples inspire the reader to take action, as in, now.
5. The book eschews business plans and instead recommends to use your time more effectively by just trying to sell something and letting the market decide whether you've got a good business.
6. The authors have real startup experience.
7. What's more, they have taught classes that helped students to start new businesses. (In one class, they set up a business importing chairs from Pakistan and made a health profit out of that one-time business.)

The underlying themes of School for Startups is to take action, start small and start simply, persist and learn as you move along. If you've been mulling over starting your own business, this is the book I would recommend you read.

Highly Recommended:
School for Startups is by Jim Beach, Chris Hanks and David Beasley. Check it out at Amazon.

Two health information systems: Mu and Delta

I am excited to report that my team and I are slowly building a portfolio of health information systems. Our first major project in this growing sector was Project Mu (a codename, of course). Technically, Mu is a clinic information system -- it helps manage a chain of clinics with branches spread all over the Philippines. 

Mu contains software modules to record patient demographics and health records, including diagnoses and treatment histories. It also has a module to generate price quotations and record payments (stopping short of generating receipts -- the client recognized that we weren't building a POS or point of sale system). Mu's application and database are web-based and accessible through a private cloud. Mu was delivered and deployed last year and we are now in the process of enhancing it, based on customer requests. 

Our team is proud of Mu because our clients are happy with the product (in fact, they've been giving us repeat business). We also celebrate the fact that we completed this app despite overwhelming obstacles attached to the client's circumstances (details of which I could not reveal here -- suffice it to say we overcame great odds and still came out with a good product).

And now we have two more forays into health information systems. Of the two, I'd like to write here about Project Delta. The Delta system is now in its inception stage. Like Mu, Delta will contain modules for storing and retrieving patient data, recording doctor's notes, and generating treatment plans and recommendations for patients. I am not yet at liberty to reveal details, but I promise to blog about it as soon as I get clearance from my clients, who are doctor-specialists.

What is exciting about Delta is that it will support physician-specialists who are relatively mobile -- that is, doctors who run their practice in various clinics and hospitals in different locations. Imagine Dr. M. who brings a laptop to the clinic. When she sees a patient, Dr. M. records her findings in Delta running in her laptop. If there's an internet connection, the app will update the patient information stored in a cloud database server. There may also be an app for iPad or an Android tablet that would allow a doctor to view patient records and record some notes using that mobile device. 

Of course, this is the product vision for Delta. We won't necessarily deliver all of these at the start. Our cooperative customers understand the importance of iterative development and starting with simple features (a rarity in the IT industry). So our first sprint will be just about the basic patient data and the important data entry forms.

By the way, the second exciting feature of Delta is that we are developing this entirely from a scrum approach. Even more exciting is that we are using online tools to improve our virtual collaboration, not just for the development team, but also with our clients who, as I've mentioned, are mobile physicians. I'll be blogging more about the approaches and tools we're using to start up Project Delta.

Jeff Bezos on believing and persisting

In a previous post, we talked about two key starting points for change: belief and persistence. Forbes magazine recently came out with an insightful piece about how Amazon.com grew to become the giant that is is today.

Bezos: [...] Our first shareholder letter, in 1997, was entitled, “It’s all about the long term.” If everything you do needs to work on a three-year time horizon, then you’re competing against a lot of people. But if you’re willing to invest on a seven-year time horizon, you’re now competing against a fraction of those people, because very few companies are willing to do that. Just by lengthening the time horizon, you can engage in endeavors that you could never otherwise pursue. At Amazon we like things to work in five to seven years. We’re willing to plant seeds, let them grow—and we’re very stubborn. We say we’re stubborn on vision and flexible on details.

In some cases, things are inevitable. The hard part is that you don’t know how long it might take, but you know it will happen if you’re patient enough. Ebooks had to happen. Infrastructure web services had to happen. So you can do these things with conviction if you are long-term-oriented and patient.

Reading this excerpt made things click in my mind. If you're old enough to remember -- Amazon was in the red in its first 3 to 5 years. Despite this, Bezos persisted. Shareholders kept believing and investing in the store. Amazon kept wowing its customers even though they would lose money doing this. (I know some friends who got 2 copies of books they bought because the first shipment didn't arrive on time, so Amazon Fedexed replacement copies to rectify and then the first set of books arrived a week later). 


Just imagine. You're a fledgling company, you're losing money because you're not reaching the right  sales volume, and you insist on delivering great customer service at a loss. Most would have given up. Bezos believed and persisted and slowly, Amazon thrived. I especially like the last part of the excerpt on ebooks ("they had to happen" -- what faith this exhibits!). Bezos was ahead of his time and waited and waited and waited. 


To compare: as an IT businessman, I also saw that ebooks were coming (way back in 2001). So I made this proposal for an ebook store and sent it to some local book publishers and distributors I knew. They gave a lot of excuses. They hemmed and hawed. My faith on my proposal was weak and I threw away my proposal. Ten years later, I am buying ebooks. If I only persisted, I would have become a pioneer here in the Philippines. Today, I've made peace with this and treat it as an important lesson for me and my students in change management class.


If Amazon did not have a long-term vision in mind, and Bezos wasn't persistent, and his stakeholders weren't convinced of Amazon's long-term vision, then we wouldn't be seeing much of Amazon these days. I am thankful that Amazon and Bezos were stubborn. 


Read the full article on Bezos and Amazon here. 


Read the previous blog post titled "Believe and persist in your advocacy"

Believe and persist in your advocacy

All IT and software deployment projects are change management problems to solve. If you don't handle the change management aspect very well, your deployment will fail. 

* * * 

In my change management class (which we formally call Leading Organizational Change), I always emphasize that the first step in advocating for change is to first believe in that change. Have you encountered salespeople who tried to sell you something but didn't really know what they were talking about? They came across as insincere and nothing they said could sway you to believing them.

In the same manner, if you don't believe in the change you're pushing (it could be an IT solution like an intranet, an information system, or even a community effort like a school feeding program), your target audience (aka intended users or stakeholders) will sense your insincerity. You will come across as fake and you will blow your chances of making change happen.

On the contrary, when you believe in the project you are rolling out, you will have a genuine concern for people who are resisting your efforts. You will ask them why they are not buying into your effort and you will find ways to convince them about it.

I had an epiphany when I was considering switching to a Mac. For about 23 years, I have been a user and staunch defender of PCs and Microsoft. A Mac store attendant tried to convince me to switch. He asked me what was making me hesitate and I told him that I feared the Windows tools I was using (like MS Project and Visio), wouldn't be on the Mac. Without speaking a word, he activated BootCamp and started up Windows on a Macbook. That was my turning point. It started with a store attendant being genuinely concerned about my issues.

When you believe, you win over people. More importantly, you gain another strength as a change advocate: persistence. Persistence will help you survive through resistance and opposition. 

As the person leading change, you are put in a dangerous position. Heifetz and Linsky point out in the book Leadership on the Line that your opposition will try to use politics, seduction (offer you distractions to divert you from your advocacy), and character assassination against you and/or your project.

Once, a livid representative from a customer company threatened to kick our team out of a project (that's a different story to tell). Our team thought the customer company would benefit a lot by using a new but very flexible Technology X. We found out later that Livid Representative was leading an in-house development team who was creating a similar solution using Technology Z. They probably wanted to claim credit for discovering and creating the solution for the company. Hence he threatened to kick us out of the contract. Of course, our team stood down and grudgingly supported what the in-house team was doing (after all, we were only contractors). It was a clunky and dirty technology -- we knew because we had a taste of the power of Technology X.

We swallowed our pride, but we persisted in using and promoting Technology X. Years later, the company rehired our team to deploy exactly what we previously recommended to them. It turns out that the company grew dissatisfied with their in-house team and the Solution Z. Desperate, they hired an independent IT consultant who recommended -- guess what? -- Technology X.

We secretly gloated and we knew we wouldn't have reached this goal if we gave up that early.