Monday, December 14, 2009

They stole my startup idea

I recently came across a series of posts by Steve Blank on how couple of his ideas were stolen. This reminded me of somewhat similar thing happened to me a few years ago. I want to get it off my chest by sharing it here. So, here it goes.

In 2004, I was toying with a business idea that I had for sometime and finally decided to put it on paper and get some feedback. I was still working a full-time job then. The idea was about leveraging the growing popularity and penetration of mobile phones in the villages of Bangladesh (that's where I am originally from). Although the poor farmers were using the phones to find out prices in the market, but it was limited in scope. The farmers were still going through the middlemen who were taking advantage of the price arbitrage that existed because of lack of market information available to the farmers. So, I thought what if we enabled a market place over this growing network of mobile phones and help cut out the middlemen. Fittingly, I called my venture " Grameen Bazaar." I thought who would be better to seek advice from than the person behind the company called "Grameen Phone" that, in partnership with the "Grameen Bank" (the organization behind the micro lending), brought the phones to the poor. My expectation was to see what he thought about the idea and possibly convince him to get involved in some capacity. So, I contacted him by email and sent him my biz plan. Then scheduled a phone call to discuss my idea. I was excited to talk with him on the phone only to be disappointed. He was less than encouraging. He was busy with other ventures that he would not have time to help me out. So, what I did as most wanna-be entrepreneur would have done- shelved my idea and moved on.

Fast forward a couple years. It was 2006, I finally quit my job to plunge into my first entrepreneurial venture (Code71 and ScrumPad). I had to travel to Bangladesh (that is where I setup our offshore development center). At that time I came across this new company called "Cell Bazaar." I naturally got interested and did some digging around. To my surprise, I found out, you guessed it right, that the founder of the company sure enough was the younger brother of the person I had spoken to about "Garmeen Bazaar." I was sad to learn this, not because they pursued my idea, but because I was not acknowledged in some manner- privately or otherwise.

I was happy to see someone working on an idea that I also thought worth pursuing. I subscribe to the idea that Seth always preaches- spread ideas, don't protect them. I understand that the fact of the matter was I just had an idea and did not act on it, and someone did. I guess I just wanted to see a little professional courtesy extend to me when they had decided to pursue the idea by dropping me a line-

"Hey, My brother decided to pursue the idea you shared with me. If you are still interested, let's chat again."

Am I being too sensitive about this whole thing? What do you think?

Wednesday, December 09, 2009

Lessons learned as a SaaS startup product owner

It's been almost 2 years since we (Code71) embarked on a journey of building a SaaS product called ScrumPad. I have been playing the role of a product owner (PO). Although I have played the PO role on projects/products for our customers, being a PO of your own product is quite different. I thought it would be good to take some time and jot down my experiences so far. So, here it goes:

Minimum viable product (MVP). Initially I did not really think in terms of let's build an MVP and put it out there for feedback & iterate. We took on this initiative to meet our needs based on our dissatisfaction with the choices available in the market at the time. So, I gave a free reign to my team to build out features. We were stung by that "SNT" bug as Dharmesh puts it. The results was, you guessed it, a sprawling a set of features. When we realized that we had piled on too many features too quick, it took us sometime to cleanup the clutter. It still is not easy, but I am getting better at restraining my and my team's enthusiasm around new features.

Usability and performance. We were focused on features rather than usability in the beginning. We thought getting the features right is more important than making them feel right. Boy, were we wrong! It hurt us more than anything else. We are still working on getting this right. I realize that this is an on-going effort. You are never done with usability and performance. In the Web 2.0 world, it is in the front and center of any product development. I now have at least one story in each sprint that focuses on usability and performance.

Brand. I thought a nice logo and a design theme can always be added later. So, I continued to put it off until when I realized lack of it is causing inconsistency in user experience. When we added a well thought out design with logo, the impact was clear. I wish we did this at the beginning. We could have saved some rework and retained some early adopters. A product without a design theme is like a boat without a radar.

Idea, Build, Product, Measure, Feedback, Learn. Yes, this is the "lean startup" cycle introduced by Eric Ries. This is Agile applied to Startups. Although we were doing Agile/Scrum even before we started working on our ScrumPad product, it was limited to only our engineering process. I came across the "lean startup" framework when I met Dave McClure and Erik Ries this September during the "Geeks on a Plane" trip to Europe. I realized what is missing from what I am doing as a PO is driving product development decisions based on the rigor of "measurement-based learning." We had a basic tracking (e.g., basic Google tracking, custom "project activity index") setup. It was not anything close to what Dave describes in his AARRR (Acquisition, Activation, Retention, Referral, and Revenue) framework for startups. Even the minimal tracking (project activity index) we put early on helped us quickly detect a potential issue we had with our initial setup process after registration. However, I always was torn between working on "a product feature" vs. "a tracking feature." Always the former would win over the later. Now, I realize it is not one or the other. They are one and the same. I need to rollout a feature along with the ability to track and measure its impact on one or more AARRR metrics.

Charging early. When we decided to open the door to our service for others, we offered it for free. It did not feel right to ask people to pay for a product that is in early development phase and not stable. I thought I would not get people to use our product and provide us "useful" feedback if I charged. The reality was quite the opposite. Yes, we saw people singing up for our service. We were excited. We were getting some feedback, but none took the time to point out what was working and what was not. So, we continued to focus on thnigs that did not matter to our users. Sure enough, when we finally thought we were ready to start charging for our service, the users fled in all directions. It was demoralizing for us, but interesting to me to experience it first-hand the importance of "charging early, and often." It took us some time to build our user base back again. This time with the fees in place, we see a stark difference in the quality of feedback. It is because now the users have a skin in the game.

What kept us alive? As you can see I made all the mistakes I can make as a first time entrepreneur PO. However, I believe we did a few things right that helped us survive our mistakes so far. First, we were putting out a new release every two weeks since we started working on ScrumPad. Second, I was able to muster up courage to stop adding new features and focus on re-factoring to get us back on track. Last but not least, I ignored the temporary inconvenience to users when we were making changes to the look and feel incrementally, even if it meant some parts of our site looked completely different from another.

Now with 2010 around the corner, I am ready to drive our product development pivoted in the lean startup concepts. I'll report back on how it is going some time next year.

Are you a PO of a startup SaaS product? I would love to compare notes. Please drop a few lines.

Friday, November 20, 2009

Why open-source project management tools do not flourish?

Unlike other open source tools, the open-source project management (PM) tools are miles behind from their commercial counter parts. I have always wondered why? Most of the projects have very low development activity, if at all. Did you wonder why too? Recently, I attended a DC Scrum user group meeting where we were discussing why we chose the tools that we are using to manage our Agile projects. Suddenly, I had this "aha" moment.

If we think about it for a moment, we will realize that we all have different ideas as to what to expect from a PM tool. We all know what some of the core features should be, but we most likely would disagree on how to go about implementing them. These differences are not technical in nature. We can be very opinionated about the details of these requirements. It is like choosing what to ware. As a result, most project management tools embody the view of the development team, the product owner to be specific. As a user, we choose the one that most closely matches our view of the world. Even if we somewhat like one, we would move on to something else and would not have the patience to wait for the tool to catch up to our taste. We act like we have ADD when it is about choosing a PM tool.

Since these open-source projects do not have a passionate product owner, there is no single ownership of a cohesive view to pursue. As a result, a developer will start working on implementing one because he has this unique idea about what this PM tool should look like, but will find it difficult to have other developers to agree with that view. Worse, he will find it even more difficult to find users who will like his view and support his effort by actively using the tool. Heck, even the developers would not use their own tool to manage their project. We know an open-source project would need an active user base to sustain and flourish.

The only way to have a project management tool to survive is a team's persistence with the tool in the early stage of the development. This is only possible in the commercial world. Each of these companies are pursuing their unique vison of what a PM tool should be in the hope that there is a large enough user base (who subscribes to this vision) to sustain their development. Thanks to all these companies sticking to their guns irrespective of the diverse nature of a very discerning users group (that is us).

Wednesday, November 11, 2009

Should fixing bugs contribute to a team's velocity?

I get this questions often. I am sure you probably also got this question at one time or the other. There are two ways to look at this- value vs. cost. These perspectives are linked to how you define velocity. Let's look at both in more details.

Value perspective. If you define velocity as the net value (in story points) delivered to your customer, then you should not include bugs in your calculation of velocity. Think about it for a moment. Bugs are something that are not working as expected, but the customer has already paid for them. So, by fixing bugs you are not really delivering any "incremental value" to the customer. If you increase your velocity by including bugs, you are inflating your velocity. Now, granted that sometimes we report something as a bug when it is an incremental feature. You need to work with your product owner to negotiate to change those bugs into stories and account your effort for them in your velocity.

Cost perspective.
If you define your velocity as the amount of work done by a team in a sprint, then you should include bugs in calculating velocity. Yes, bugs take effort and time to fix. Hence there is a cost associated with fixing bugs. But this makes the release planning a little bit complicated. Because you cannot know ahead of time how many bugs you may have until the release. Directly using velocity to calculate the effort or to determine the time-line for the release will most likely be off (undershoot). One way to address this is to break the velocity into two components- feature-delivery velocity, and bug-fix velocity. This is in a way going back to the first option.

I personally am in favor of using "value" perspective and exclude bugs from calculating velocity. This helps keep our eyes on the ball- delivering "customer value." As a result, we are encouraged to reduce bugs in the first place so that we can free up our capacity to deliver more value. That is why we currently do not allow users to point estimate bugs in ScrumPad.

Are you including your effort spent on bug fixing in your velocity?

Wednesday, September 30, 2009

Freemium model for SaaS pricing is broken!

Recently I got this email from one of the SaaS companies that they are going to increase the subscription fees. The reason they stated was that their costs have gone up due to a surge in subscription for their free plan. That got me upset because what they are essentially asking is that we the paid customers have to subsidize the others who are using their service for free. Although I appreciate their candor (albeit it is a mistake from marketing perspective), but I find it difficult to accept. It is not right to pass the costs you incur for your "free plan" on to your paying customers.

It got me thinking that the popular "freemium" business model is not kosher from ethical perspective. I am sure this company is not the first to find itself in this situation. It is common to offer a free plan to attract new customers. Yet companies cannot continue to pay for the free service as their free customers increase. They are forced to pass the costs along to their real customers- the ones that pay. Not everyone admits this problem. Instead all companies bake the cost of free plan into their paid plans. Don't you think it is unethical? How would you feel about paying for a service that offers a free plan knowing now that you are subsidizing others?

There is another issue with the freemium model. You start with the free plan. As you start using the service more, you need to move to one of the paid plan. Did you consider that your costs of using the service is has just gone up both at the aggregate (which is understandable) level as well as unit level (which I have a problem with)? You will never see your unit costs go down. Shouldn't it be the other way around? That is your unit costs for a service should go down as you use more. You should expect volume discount, right? The vendor should encourage more usage of it services by providing volume discount. In reality, we see quite the opposite. Talk about misalignment of goals. Win-lose or lose-win proposition. When customers use free service, customers win but vendors lose. When customers use paid services, vendors win but customer lose.

Why not we all only offer free trial and make all out plans paid plans? Nobody subsidizes anybody. Customers get an opportunity to try things out before they pay for it. Vendors do not have to worry about how to pay for free plans. Customers are encouraged to use more and get discounts. That way we all win.

What is your thoughts on freemium plan? If you are a SaaS company, how are you paying for your free plan?

Sunday, August 09, 2009

Reality check for Agile projects- working sofware over comprehensive documentation

We all have an ideal view of the world surrounding us. That is OK as long as we are aware of the real world and know how to rationally deal with it. We as agile practitioners have our own view of an ideal world. Last year I attended Scott Ambler's session on "Agile in Practice" at Agile 2008. In this talk, he challenged the common concepts and shared his findings. I found this talk very insightful and would encourage everyone to listen to this. In fact, it inspired me to write this series on Agile ideal views of the world.

I will talk about some of the "aspects" of this ideal agile world in a series of blogs. Last time I talked about "project management (PM) tool vs. no tool." The topic today is "documentation on Agile projects." This is third in the series.

The common perception about Agile projects in the market is that Agile teams follow cowboy coding and hence do not document. The myth about "no documentation" goes so far as that some see this as an incentive to adopt Agile and escape "over documentation" of the traditional waterfall projects. However, this couldn't be further from the truth. This misconception to some extent stems from misinterpretation of the Agile manifesto that says-
"Working software over comprehensive documentation"

The intent of this manifesto is to underscore the importance of "working software" and risk of "comprehensive documentation." This does not encourage us to do away with documentation altogether. I hope we all agree that the primary goal of any software project is the "working software," and the secondary goal is to support on-going maintenance and enhancement of this software. Scott Ambler refers to it as "to enable the next effort." We all know that cost of development is only 20% of the total cost of ownership of a software. To contain this cost and associated risks, we need "right documentation."

A few of the issues with the traditional documents are,

1. Documents are static. They are a snapshot in time. Hence, they quickly get out of sync with actual working software. Outdated documents increases project costs and risks.

2. Documents are created too early. Traditionally documents like requirements, architecture, design documents are created early in the project. As the project progresses, the requirements, architecture, and deign morphs. Either documents become stale or the cost of maintaining documents increases.

3. Documents are bulky. We tend to use Word doc, Excel, Power Point and the like to create our documents. They are disconnected island of information. To keep them in-sync with each other requires a lot of effort. As a result, we see a lot of repetition (wastage). It is also difficult to link information across all documents at the appropriate level using these old-school tools. For example, individual requirements to rules to test cases to decisions to etc. etc. It is difficult to browse the right related information just-in-time and just-in-place.

DDJ (Dr. Dobb's Journal) partnering with Scott Ambler ran a survey on how much documentation Agile and non-agile teams are doing. The result reveals that Agile teams are more likely to model than a non-Agile team and equally likely to create documentation.

Here are a few things I suggest to become Agile with documentation.

1. Certainly, no documentation is not Agile.
2. Find a way to implement a continuous, collaborative documentation (Wikipedia model). For example, allow end users to evolve and enrich user manuals as needed, when needed. Allow developers or support engineers to update architecture document or operational manual.
3. Delay documentation until it is requested. I call it "just-in-time documentation."
4. Keep the documents nearest the location of use (context sensitive). I call it "just-in-place documentation." For example, technical API documentation within the source code. Use tools like NDoc/Java Doc/RDoc to extract APIs accessible from IDE. User manual should be embedded through out the software.
5. Use Wiki or Wiki style tool to cross link different elements of documents to form a Web of interrelated information. I call it "accessibility of documentation."
6. Determine what to document based on frequency of use and number of consumers of the information. Importance of a document can be calculated by multiplying frequency and number of users. This could be used as a surrogate for a real ROI. The higher this number, the higher the ROI from the document. In other words, only document information that will be used by at least a group of people on a regular basis.
7. Use appropriate format for documenting information at hand. I call it "comprehensibility of documentation." For example, use "As a , I want ...., so that...." for documenting requirements. Use "given ..., when ..., then ..." (BDD style) to document acceptance tests. Use state machine diagram to document a stateful processing of data.

Scott Ambler goes in depth about documentation on Agile projects. I would encourage everyone to read the article.

Yes, documentation is a sticky topic. It is difficult if not impossible to strike a balance between amount (over vs. under vs. no) and quality (useful vs. redundant, correct vs. stale) of documentation.

What type of documents are you creating on your Agile projects? What tools are you using?

Thursday, June 25, 2009

Reality check for Agile projects- project management tool vs "no tool."

We all have an ideal view of the world surrounding us. That is OK as long as we are aware of the real world and know how to rationally deal with it. We as agile practitioners have our own view of an ideal world. I will talk about some of the "aspects" of this ideal agile world in a series of blogs. Last time I talked about "collocation vs. virtual collocation." This is second in the series. The topic is "project management (PM) tool vs. no tool." Interestingly enough, Mike Cohn recently blogged about an apparent conundrum of using a physical task board with a distributed team. Both of my blogs in this series are very relevant to what he talked about and the discussion followed it.

Since an agile team is expected to be collocated, general thought is why need a tool? Excel, physical cards, and boards are good enough. I hear people transitioning to Agile say-
"We are new to Agile, want to focus on the process, not the tool."
While I understand and appreciate the underlying intent, I find it difficult to understand why would using a project management tool get in the way of adopting Agile. It is to me same as saying-
"Well, we are new to Ruby on Rails, want to focus on learning the language, not an IDE tool."
I am sure teams that use a PM tool appreciate the importance of such a tool. For distributed teams, such a tool is essential, not optional. For collocated teams, here are a few reasons why you should consider using a project management tool,
  • A decent tool will allow you to focus on what you should be focusing on rather then wasting your time in managing artifacts (time, requirements, tracking velocity, bug, traceability- linking related items together etc. etc. ) manually.
  • Keep a trail of all conversations organized in the appropriate context even the conversations happen face to face. We all tend to forget the details we talk about. Later that comes back to bite us. A documented trail helps avoid conflicts (not to be used as finger pointing though).
  • You want to gain insights into your project so that you can do effective "inspect and adapt." Doing this manually will take away your time from your core responsibility.
  • You will get an audit trail of what happened for free. In some industries, it is a requirement.
  • If it is a client project, it can save you from legal hassle should such a situation arises. Yes, I know Agile spirit is about collaboration over contract negotiation. Remember, I said it is a reality check. In real life s**t happens even after all the good intentions from all parties.

I save the topic of what to look for in a decent Web-based project management tool for another day.

If you are not using a real project management tool (not Excel, Google docs, or even worse Microsoft project kind), please do yourself a favor and switch to a decent Web-based project management tool today. While you are at it, check out ScrumPad, the next generation project management tool. Please let me know what you pick for your team.

If you are still not convinced that a Web-based project management and collaboration tool is essential for the long term success of any development team, I would love to hear your side of the story.

Reality check for Agile projects- collocation vs virtual collocation

We all have an ideal view of the world surrounding us. That is OK as long as we are aware of the real world and know how to rationally deal with it. . We as agile practitioners also have our own view of an ideal agile world. I will talk about some of the "aspects" of this ideal agile world in a series of blogs. This is first in the series. Today the topic is "Collocation vs virtual collocation."

We all agree that face-to-face communication is the best. So much so that it has an explicit place in the Agile principles. However, we see growing number of projects have distributed teams for many reasons- outsourcing and offshoring, telecommute, multiple offices, lack of local talents etc. I think it is time for us to embrace the reality (as Agile was born from the realization of embracing the reality vs fighting it like the waterfall camp did) and update the Agile principle to say
"The most efficient and effective method of conveying information to and within a development team is face-to-face conversation in person or virtually."
Outsourcing and offshoring has become mainstream. It is here to stay for foreseeable future. It is elegantly explained by Thomas Friedman in his famous "World is flat" book. If you haven't read this book yet and want to understand the dynamics of today's connected world, I would highly recommend it.

Having a team distributed across continents is not any more a "tactical step," it is a "strategic need." Think where would Jason Fried and 37signals be without DHH, if it were not for "virtual collocation." There are many such success stories. If you are not open to working with the right talents irrespective of their location, you are at a great disadvantage compared with your competitors. Let me be a little blunt here- forget about competing.

In an increasingly crowded world, it is a growing trend for people telecommuting. Why would we require people to come together at a designated physical location everyday when a significant time and energy is wasted on the road? Why not we enjoy living in home town and being able to spend more time with family, yet have the opportunity to work on projects that could benefit from my skills and experiences?

Next generation (generation Y) are growing up in a virtual world (Facebook+SMS+Twitter+blog+iPhone). Virtual collocation is in their gene. They are forging lifetime friendship in this virtual world, coming together to support a cause, interacting on a daily basis as if they are in the same room. When they enter the workforce, they would not know anything different. In fact, they would prefer to work in companies where it is part of the culture.

So, agile practices should evolve to embrace virtual collocation rather than ignoring it, even worse resisting it. In fact, Agile is not at odds with virtual collocation. It is rather a necessity for distributed projects. There are many examples of successful adoption of Agile on distributed projects- large and small.

Yes, it is not easy to get it right. We may have to work a little harder to get it right. I would argue that getting communication right in a collocated environment isn't a cake walk either. Right communication is more than just being collocated.

I make a prediction here- in a decade or so most projects will have distributed teams. Collocation will not be a topic of conversation any more. 895gsubzpr

Tuesday, June 23, 2009

The most important software engineering practice

Continuous Integration (CI), hands down. I hope you have already heard the term if you are in anyway associated with software development. If not, I would highly, highly encourage you to read this article by Martin Fowler.

There are many practices in the Agile community, specially among XPers. Among those, TDD (test driven development), refactoring, and pair programming are other three most talked about practices aside from CI. Most of these practices have believers and non-believers.

TDD. Recently Uncle Bob preached TDD to all developers in his keynote speech at RailsConf 2009. Although I am a big fan of Uncle Bob and learned a lot from his writings over the years, I am afraid I have to side with DHH on this practice. Don't get me wrong. I like TDD, but I do not think it is a key to "clean code." Test first approach is not natural, it takes a lot of practice. Even then it may seem difficult to many developers. I am of the opinion that whether you write test first and then code or vice versa, you must write tests. But, follow what feels natural to you. That way you as a developer will have fun doing it. I agree with DHH that it is important that we have fun while writing clean codes. At the end, as a client/sponsor I do not care whether tests were written first or not, what matters is whether the software comes with comprehensive tests or not (code coverage). By the way, if you haven't seen Uncle Bob speak, you must. He is very animated speaker.

Refactoring. Although most projects/products go through refactoring at least once (if not more), it meets with resistance from all sides. Because, it comes with the connotations like low quality, incompetence, waste etc. Developers do not want to admit that their own codes need rework. The project managers do not want to ask clients to pay for something that is already done and working. The clients when hear "refactoring" becomes anxious thinking that the software that they are paying for is of low quality. The other end of the spectrum is teams can get overzealous and end up spending in this endless cycle of refactoring. So, it is difficult to implement "just enough" continuous refctoring that helps a team to maintain a sustainable forward pace on the project. When that right balance is struck, refactoring helps design to emerge/evolve as well as keep technical debt to a minimum.

Pair programing. One of the most controversial practices. I have to admit that I was a non-believer too until recently. My team has recently started doing pair programming and found it to be very helpful specially for refactoring type and complex works. It probably is not as effective for all types of work as well as every team. The most challenging aspect of adopting this practice is to justify upfront increased, however small or large, development costs and time and convince clients to pay for it. At least in the minds of clients, two persons working together on one thing at any time will look like they will be paying twice as much for the same amount of work and probably will take twice as long. It is a hard sell.

CI. It is the most accepted practice with very tangible benefits that both technical and non-technical persons can appreciate. If your team is not currently doing it, you should push for implementing CI immediately. If your team is already doing it, make sure you have the 10 elements mentioned in Martin Fowler's article. The diagram below shows the main steps involved in CI.

Most tools will generate Web reports and send email every time CI process runs. As a client, or PM, or manager, you would want to be on the distribution list for this report. Also you should learn how to read the report so that you understand what it means for your project. Even if you are not following Agile process, you can still benefit from CI.

Sunday, May 31, 2009

Containing technical debt

One of the most important concepts in Software Engineering is "Technical Debt." It was first introduced by Ward Cunningham in 1992 in an experience report at the OOPSLA. If you haven't heard the term before or want to refresh your memory, I have collected articles/blogs on the topic that I thought have done a good job of explaining it.
  • Here is Ward Cunningham explaining his thoughts behind why he coined the metaphor on wiki and also in a video talk.
  • Here is a blog by Martin Fowler on the topic.
  • Here is a personal blog by Dharmesh on the same topic.
I was at an Open Space session on technical debt at Orlando Scrum Gathering early this year. What seemed to be on everybody's mind was how to protect our projects from going bankrupt under the burden of technical debt. We all agreed that it is easy to deal with debts that we take on knowingly. The real challenge is to identify debts that creep up on us over time (like credit card debt- a little here, a little there, some missed payments, and voila...). We get caught by surprise until it is too late.

I am going to suggest a few things when put into regular practice can help you contain the debt to a minimum.

1. Low test coverage can contribute to hidden technical debt. When we are under time pressure, guess what gets cut from the budget? "testing!" It may seem innocuous to eliminate funding for "testing," it can push the project to bankruptcy when done on a regular basis. So, target 90%+ test coverage and track it through continuous integration.

2. The best "architecture" is not static, it is evolutionary that emerges over time. What is important though is "consistency." If we are always doing the same thing the same way, the chances of incurring hidden debt goes down. The consistent way of doing things needs to be a shared knowledge best captured as a list of "How Tos" and needs to be kept in synch with the evolving architecture. Do you have one such list for your project?

3. Review architecture at a regular interval to spot inconsistencies. I am sure you will find some even after you have a published "How Tos." As soon as you find them, fix them.

4. I have seen bugs are triaged and then some are deferred to be fixed in the future in favor of some "important" new features. The fallacy lies in the notion that cosmetic/minor bugs are harmless. What is harmless today can compound into a significant issue later somewhere else in the system. Personally, I always like to fix all bugs before I do any new development. However, I can understand that we may need to do it at times, but it should be "exception" than "norm."

5. Last but not least, if you must take on a debt, get a commitment to payback in full by a specified timeline. Then track and report on it like a hawk (not like the Fed or SEC).

How are you containing technical debt on your project? Care to share?

Wednesday, May 20, 2009

Why should you consider Ruby on Rails for your next project?

I am sure many of you are asking yourself- so, why should I use Ruby on Rails (a.k.a. RoR) for my next project? I am going to share with you why I would. It is the Rails, the application framework, that is the force behind RoR. What Rails does is constrains developers in this predefined application structure with necessary elements required to build a reasonably good enterprise/commercial strength Web-based solution. Constraints can be liberating. It is certainly true for RoR. As a result, you can expect to build an application of reasonable quality with a less experienced/young team faster than any other technology, for example, Java/.Net (assumption is the team has the same years of experience with both technologies ). The database migration tool that it provides to help with incrementally building the database alone can be reason enough to give it a serious thought. Rails' simple yet elegant plugin architecture have fostered a large active community of plugin builders. You can find many useful plugins that are needed for many applications. These plugins could speed up your development time even faster.

We all know imitation is the highest form of flattery. It is true for Rails too. Rails has inspired many copycat frameworks in many languages. Even Microsoft has taken a notice of it. Microsoft has recently published its Rails-inspired MVC framework for its .Net platform. Please remember, these Rails-inspired MVC frameworks do not give you all the things that you get from Rails to make your team hyper productive.

While RoR philosophy of "Convention over Configuration" contributes to developers' productivity, it could also be limiting for certain situations. RoR is good for new applications as well as porting existing applications where your existing databases can easily support "Single Table Inheritance" in your domain.

I have heard many expressed concerns about Ruby's performance because it is a dynamic language. It reminds me of Java's early days. We have come a long way since then. We have many high traffic RoR applications in production. Ruby is now supported on Java VM through JRuby and on .Net CLR through IronRuby. Performance should not be a concern for RoR applications that can also be built using Java or .Net. If you are not convinced, here is a very good case study on that should remove all your concerns about RoR. If you are still not convinced, David Hansson, the man behind the Rails, talks about why scaling with RoR is boring...:-)

Are you considering RoR for your next project? Did you recently complete a RoR project? Please feel free to share your experience with us here.

Monday, May 18, 2009

The Dream Team of Agile Software Development

If you had to put together the best team possible for the most complex project and money is not a concern, who would you have on your team? I can tell you who would be on my "The Dream Team."

Product Owner- Mike Cohen

Scrum Master- Ken Schwaber

The Development Team

Kent Beck
Bob Martin,
Jim Copline,
Martin Fowler,
Alistair Cockburn,
Ward Cunningham,
Jeff Sutherland,
Ron Jeffries, and
Jim Highsmith

I am making an assumption that they all still write software and will be able to work with each other...:-) Now the questions are-

  • Is this team going to be the most hyper-productive team ever in the history of software industry?
  • Are they going to follow Scrum? Or, are they going to come up with something new? Should we call that "Scrum But?"
Just wondering. Unfortunately, the reality is much more constrained. We need to work with a team that we can reasonably put together. The reasonable expectation is to have individuals who are average. I always wonder why people are so obsessed with hiring the best/brightest from Standford or MIT. I guess I do not fall in that category (and hence the grape is sour!)...:-) However, I sure can bet my money on my team that it can go head-to-head with any dream team in the world. I am sure so is yours.

The focus should be "The Team," not the individual. Do me a favor, when you look for a new team member, mention in your Ad- "Looking for the best team member."

What do you think? Who would be on your dream team?

Wednesday, March 25, 2009

Orlando Scrum Gathering 2009

I just came back from the gathering last week. It was different this time from the past gatherings in that this time the event was graced by the presence of industry heavy hitters like Ron Jeffries (Co-developer of XP), Jim Copline (The author of "Advanced C++" that helped me shape my understanding of C++ and OO early in my career), Alistair Cockburn (famous for his book "Writing Effective Use Cases" and Agile process called "Crystal"), Dr. Mark Paulk (led the work on CMM at SEI), and last but not least Gregory Balestrero (President and CEO of PMI). As you can see from the lineup, Scrum Alliance has done a great job of inviting these people and initiating an industry wide collaboration around software development process.

What to expect in the coming months? Scrum Alliance has engaged Dr. Paulk to do empirical research on Scrum. He is going to focus on Agile and Scrum practices and help the Agile community to understand what practices really contribute to the success of projects. With the inclusion of PMI, we would see more and more practices being included in the PMBOK. There is a growing trend among PMPs to adopt Scrum and Agile practices. A group of PMI members has already formed a pmiagile Yahoo group to promote agile practices within PMI. This group has been officially recognized by the PMI.

What's Scrum community grappling with? From the types of discussions I heard at the event, it seems the adoption of Scrum has come a long way. The top things now-a-days on the minds of most Agile teams are,

  1. User Story vs Use Case. It was thought that User Stories are going to replace Use Cases. However, it seems people are still using Use Cases (especially on large projects) in at least some light weight format along with User Stories as they lack high level contexts. Jeff Payton's "User Story Map" technique to address this gap in User Story is becoming popular. He was at the gathering and offered sessions on it. Alistair is a vocal advocate of continuing to use Use Cases. Surprise, surprise...:-) He wrote an article on User Stories vs Use Cases for the Lean magazine (I thought I could get the article from Alistair's site or from the magazine's, but I could not).

  2. Agile Architecture. Jeff Sutherland and Jim Coplien had a session on how architecture can help a team becoming more Agile. There is a trend among Agile teams to only rely on continuous refactoring to have a suitable/consistent architecture emerge over time. They lose sight of the importance of starting on the right foot with some upfront "architecture thinking." Jim is working on an new architectural pattern called DCI (data, context and interaction) that could set the OO developers free from the shortcomings ("algorithm" part of the stories is usually scattered among many domain entities/models and get in the way to becoming Agile) associated with MVC.

  3. ScrumBut. Most teams can be considered ScrumBut, a termed coined by Ken Schwaber (I think) to point out how teams are not taking full advantage of Scrum practices. While the intent of ScumBut is to help team identify where they have improvement opportunities, it is creating confusion and frustration in the minds of the practitioners in that if there is such thing called "Pure Scrum" (which seems to be an illusive target). The whole confusion around the term ScrumBut (which gathered more negative, almost derogatory, connotation than it was intended for) lies in its definition based on a check list of mechanics. In fact, it was brought up in the panel discussion at the gathering that the definition of Scrum as found on the Scrum Alliance site as 3 roles, 3 rituals, and 3 tools hide the true essences of Agile captured in the Agile Manifesto. The mechanics are there to help teams get started, but they, by no means, are "sliver bullets." Each team needs to find its unique practices (customized through "inspect and adapt") that help them incrementally deliver working software that maximizes value for the customers.
Alistair nicely summed up the underpinnings of Agile process movement this way,
Self-awareness (focus of Crystal), self-discipline (focus of XP), and self-organization (focus of Scrum).

Thursday, March 12, 2009

Best Practices for Amazon Web Services (Amazon Cloud)

We run our ScrumPad (A Web-based project management tool) on Amazon cloud (AWS). We have been using Amazon cloud for last year and a half. We did not have any issue with it until recently, when we found out that we had lost shell connection to our production server. Although the application was working fine, we went into a panic mode realizing that we won't be able to do anything, should we encounter any problem. Once we calmed down from our initial panic attack, we quickly searched on the net to see if anyone experienced the same issue and how they recovered from it. We did not get any hit on it. There is always first time for everything. We thought to ourselves that the solution is easy with AWS. We would just bring up another EC2 instance and point to the new instance. Right? Not so fast. We found out that we were not using elastic IP. That means we need to make DNS change, which takes up to 24 hours to propagate and may result into some data loss and/or service downtime.

This incident helped us to think through how we should be using AWS and here is what we have come up with:

1. Always use elastic IP (behaves like a static ip) to point to your EC2 instance. You can then quickly swap instances without needing to make any DNS changes.

2. Always use EBS (elastic block storage) instead of the storage that comes with an EC2 instance to store your Database data . You can then quickly reattach your data store to a new instance as well as you will not loose your data in the event of EC2 instance failure and have your data automatically replicated.

3. Spread your EC2 instances to different availability zones and regions instead of putting them all in the same availability zone (a physical data center). You can then protect your application from single data center failure.

4. Backup (incremental snap shots) your database from EBS to S3 (Simple Storage Service), which is automatically replicated across multiple availability zones.

5. Create a custom AMI (Amazon Machine Image) for your application from a pre-configured public AMI. You can then bring up a new instance quickly (in less than 15 mins) on-demand and even completely automate server provisioning.

6. Rollout your new release to a new instance(s) when you need to change your AMI (i.e., when you upgrading your DB, OS, Application Server, etc.) and then reattach your elastic ip and EBS to this new instance. You can then quickly rollback to the old instance should you encounter any problem with the new release.
Figure: How to transparently switch to a new instance

7. If budget permits, use cloud management tool like RightScale.

With a few practices in place, you can have your own virtual data center (on Amazon cloud) that was only available to large corporations.

Thursday, March 05, 2009

Are You Getting The Most Out of Your Daily Scrum?

I was recently out on a six-week trip to our offshore development center in Bangladesh. When I came back, I found out that the Scrum team I am coaching has changed the format of the Daily Scrum. They were doing the Daily Scrum in the traditional stand-up format in front of a physical task board. However, we always felt that the Daily Scrum was not as effective as we want it to be. We tried different things in the past to make the most out of our Daily Scrum. Nothing seemed to work, and hence always fell back to the basic format.

The team is now using a projector to use the electronic task board available in ScrumPad during the Daily Scrum. I, to be honest, was surprised and a little skeptical at first. The team felt that this new format is helping everyone better follow what others are saying in the Daily Scrum. It seems the verbal communication is being reinforced by the visual elements. It remains to be seen that how long we can continue to follow this new format.

One of the challenges of traditional Daily Scrum is to really "listen" to what others' are saying. An effective daily Scrum should allow everyone to understand how individual work is contributing towards achieving the team's Sprint goals. Anytime the team falls out of sync, it should become obvious in the Daily Scrum. And the team should take appropriate steps to recover/compensate. Thus the Daily Scrum works as "a daily feedback loop" to keep the team on the same page. It is easier said then done though.

How effective is your Daily Scrum?

Saturday, February 28, 2009

Pairing or Pair Programming "XP Style" on a Story?

I never liked the rigid position taken by the XPers on "Pair Programming"- one programmer typing away while the other sitting next to him watching over his shoulder. People, particular PMs and clients, are weary of this practice thinking that it is a wastage of time, and hence money. I am with the PMs and clients on this. I don't like this practice because this not how we the programmers naturally work. And hence it cannot be as productive as it is claimed to be. Yes, I know there are studies throwing numbers like "15% improvement in quality while only 15% slower than two solo programmers." Why would I want to be 15% slower (hence pay 15% more) if I can maintain the same quality (difficult to prove either way though)?

I understand how this "pair programming" came about. What we the programmers naturally do is that we talk and interact with our fellow programmers sitting next to us or in front of us as we work on our codes on a daily basis. Sometimes, we look over our fellow programmer's shoulder to help or to be helped. This is natural. However, formalizing this is over the top.

What we have been doing at Code71 is what we call "Pairing on a Story." That is, at least two developers pair on a single story and take on different tasks. They coordinate to deliver the story. We usually like to pair novice-expert. This way you avail all the advantages of pair programming without the disadvantages as well as get the support from the PM or client.

Are your pairing or pair programming? Like to share your experience?

Thursday, February 26, 2009

Two Essential Components of Any Startup Anywhere in the World

When I started my company two years ago, I focused on things I felt were important to get the business off the ground. That was, creating the service and product. Things were going fine until recently when we found ourselves in need of emergency accounting and legal help. On the accounting side, we came to realize that we need a big help from an expert accountant to fix our (accounting) books (for processing a loan). On the legal side, we found holes in our Articles of Association/Articles of Incorporation and MOA (Memorandum of Association) when we needed it to resolve an issue. We are ending up spending more money than we would have had we done it right the first time. The worst thing is that we might miss a business opportunity now because we short changed the process when I setup of our business.

So, if you are starting your business, do yourself a favor by finding a good accountant and a lawyer. If you are setting up a business in a developing country, it is even more important. There is a tendency among entrepreneurs, especially the first timers, to downplay the need for an accountant and a lawyer. Ok, I understand you want to spend all your limited startup capital on the core business. Please don't wait too long like me though. Make sure that the structure of your business is setup to succeed.

Sunday, February 01, 2009

Is Your Architecture Agile?

One of the less understood and hence less discussed topics of Agile software development is Architecture. Traditionally architecture is seen as an involved process (if done) done by some elite group of technologist called "Architect." They create these blueprints and visions that are very difficult to understand and hence probably unrealistic to implement. That is why Agile community probably carefully avoids talking about it. We cannot ignore it, yet we cannot live without it. If we do it the traditional way, we cannot be Agile. This has created a misconception among many that Agile community has discarded architecture. This cannot be further from truth.

Having practiced Agile/Scrum on small and large projects for last few years, I thought about collecting my thoughts on Agile and Architecture. So, I figured the best way to create some guideline on Agile architecture is to create a test to determine whether an architecture is Agile or not. Here is the "Agile Architecture Test,"

1. Can you describe your solution using standard well-understood solution concepts (i.e., CRM, ERP, DW, e-commerce, etc.)?

2. Can you describe your solution in terms of one or more well-known architectural patterns (i.e., MVC, Hub and Spoke, Pipe and Filter, etc.)?

3. Can you describe your solution in terms of COTS/Standard products/components (Web Server, Application Server, Integration Server, ORM tool, Database, framework etc.) using a simple block diagram?

4. Can you describe your solution in terms of a domain specific framework?

5. Do you estimate features in terms of components of the framework (domain specific) needed to be modified and/or added?

6. Do you build and run regression test as often as there are changes committed to the system?

7. Can you deploy your entire solution at the push of a button to any environment (i.e., test, integration, production, etc.)?

8. Can you determine the health of your end-to-end system at any point in time in a minute or less?

9. Does your system notify you when something is not working?

10 Can you determine cause of a problem in your system in less than 30 minutes?

9. Can you run multiple versions of the solution in the same physical environment?

10. Is your test environment an exact replica of your production environment?

11. Is your dev environment an exact replica of your test environment?

12. Can you define your production environment as a multiple of your test environment in terms of deployment footprint?

13. Can you do load testing at will?

14. Is your solution database independent?

14. Is your solution, if applicable, supports all browsers?

15. Can the deployment footprint of your solution grow and shrink with the load?

Some of the questions are more geared towards solution using cloud computing environment like Amazon Web Services. I believe cloud computing has greatly enhanced the agility of a solution architecture.

If you spend more the two weeks (sprint 0) on architecture, then you are over thinking it. Jeff Sutherland and Ken Schwaber echoed the same at the Fall Scrum Gathering in Stockholm last year. If you have an enterprise architecture guideline, that is even better. Some of the decisions have already been made for you. Architectural constraints can be liberating.

OK, I might be oversimplifying here. Sure, there are edge cases. But, the point is that most systems do not fall under the edge cases. I will be interested to know what you think of this test of agility of a solution architecture.

SoftExpo 2009 and Some Thoughts

SoftExpo 2009, a 5-day software exposition in Bangladesh, organized by BASIS just ended yesterday. I am a little bit tired from it. It is not so much a physical exhaustion as it is mental. However, I thought I should jot down my experiences while it is still fresh on my mind.

It was first time for me as well as for Code71 at this Expo. It was at least a month long preparation for Code71 with much anticipation for another few months. Code71 had a booth where it exhibited its flagship product ScrumPad as well as its custom software development services. Code71 also organized a seminar on "Agile/Scrum" and I was the speaker. It was a great all out effort by the team. Kudos to the team.

As for the seminar, I was not sure what kind of crowd I could expect. To my surprise, the turnout was great. Some of the companies are already using Agile/Scrum in some form or fashion. My goal was to introduce the Agile/Scrum concept to the local companies. My message was Brand Bangladesh in ICT = “Agile.” Indian IT outsourcing companies flourished based on CMM strategy. Bangladesh needs to catch the wave of Agile before it is too late. I plan to write a follow-up blog on the strategies that Bangladesh needs to adopt in order to be successful in establishing Bangladesh as a prominent destination for IT outsourcing.

On the whole, the Expo was well organized. The seminar topics were well chosen. BASIS has done a good job of inviting the government officials and pushing the agendas that need immediate attention to bolster the ICT sector in Bangladesh. The timing could not have been better since the newly elected government campaigned on the platform of "Digital Bangladesh by 2021." I attended some of the seminars. It was clear, as everyone knows it, that allowing e-payment (specifically the use of local credit card on the net) is the highest priority on every body's mind. It seems, other than government's lack of understanding (technology behind) and bureaucracy, some laws relating to dealing with payment disputes are for paper-based transactions and hence need face lift before e-payment can be enabled. Once the e-payment is enabled, expect to see flurry of consumer as well as business services to flourish. Hopefully we will see this come live sometime this year.

One thing that was missing from all these was any focused activity (i.e., match making, seminars) around IT outsourcing. I would say BASIS has dropped the ball on match making. There were a couple seminars on outsourcing, but nothing on what or why Bangladeshi companies are not being able to get any traction and what can be done. Maybe given the economic condition around the world, BASIS could not get any buyers to attend the Expo. Hopefully, IT outsourcing will get the right attention that it deserves and not just a lip service next year. I and Code71 hope be back next year.