Saturday, December 17, 2011

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:
If you know a good solution for our technical issues and requirements, do send me a comment. Will highly appreciate it. 

Tuesday, December 13, 2011

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.

Monday, December 12, 2011

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.

What to do when you've got a virtual scrum team

Scrum and Agile are suddenly popular in Asia, and because a lot of companies take on outsourced projects, they usually have virtual teams, w...