Thursday, November 19, 2009

Opt-in from a Trial to a Paid Subscription

Yes, we have listened to our users. Now your 30-day free trial subscription will not be automatically converted into a paid subscription at the end of the trail period. Although we send an email notification a week before a trail period comes to an end, it seems users may not act proactively to cancel their trail subscription. It was never our intention to mislead our esteemed users to signup for a trail subscription only to convert them into a paid one. We wanted this to be a convenient feature, should anyone decide to continue to use ScrumPad. They can continue to use the service and keep their data. However, we realize that how people can forget to cancel subscription in time and then be surprised later when they receive an invoice. We never require anyone to pay for a service that they did not use. In fact, we do not take our customer's credit card info and do not charge customers' CC automatically when payment is due. We only invoice at the end of the month after our customer used our service for the month. Customer has the option to pay or ask for waiver because they are not happy with the service that month.

So, from now on you can upgrade to a paid account anytime during your 30-day free trail period. Or, your trial account will automatically be suspended after the trail period. If you try to login after the trial has expired, you (account admin) would be prompted to explicitly agree to upgrade to a paid account. Once you agree to upgrade, you can continue to use your original account without loosing any data. You will still receive an email reminder one week before your trial account expires.

We are happy to be able to make this change. We hope there will be no confused users either.

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?

Thursday, October 22, 2009

The ScrumPad Way- Project Ecosystem

If you are reading this post, chances are you are already using ScrumPad, or thinking about using it. We believe your decision to choose our service should not only depend on what we have today, but also on what we plan to have in the coming days. More important, you should know what drives those decisions. Let us share with you our vision for ScrumPad, the philosophies behind it.

We believe that there are two very important tools that every software development team must have- one is for Project Management, and the other is for actual software development (which we all know as IDE -Integrated Development Environment). These two tools should have tight integration between them to create what we call the "Project Ecosystem." A clear division of responsibility between the two tools would allow us to establish that ecosystem that feels "just right." It can be explained through the following diagram:

What this means is we would only focus on features that would be most appealing to the broadest group of users on a project. We will leave out product integration or features that we see are more appropriate for IDEs. For example, integration with a "CM" (i.e., SVN) tool or a "testing" tool, or "continuous integration" tool is better suited at the IDE level. Integration with, on the other hand, an "invoicing" system or a "help desk/trouble ticket" system is more appropriate for ScrumPad.

So expect to see integration with popular IDEs and Invoicing services in the near future. We are currently working on publishing APIs to facilitate these integrations. If you are enthusiastic about creating a plugin for your favorite IDE, please contact us. We would love to support your endeavor.

Now that you have an idea about how we decide what features to consider for ScrumPad, let's talk about how we go about implementing them. Our implementation is always guided by the principle of "convention over configuration" as much as possible. For example, we do not allow configuring a workflow, or what is displayed in a view, or what reports you can generate, or what you see in a report (but we will add reports that all of you ask for). WYSIWYG- what you see is what you get. We try to take the common denominator approach to keep things simple, yet very useful and comprehensive. We believe that you can get the most value out of a PM tool when you do not have to think about how to use the tool. You should spend the least amount of time with the tool to get the most value out of it. As a result, we try to do most of the work for you where possible with minimum input from you.

Last but not least, we believe software project success depends on appropriate "collaboration" within and across teams. We are taking it to the next level by opening up collaboration across companies- "ScrumPad community." If you have an idea on how companies can collaborate to achieve project success, please share with us.

Also, please note that we are making changes (i.e., fixing bugs, experimenting with a new feature, improving usability, performance etc.) to ScrumPad every two weeks. Be prepared for an exciting ride of "evolutionary product development." We expect you to be an integral part of that ride to build the "Project Ecosystem."

Do you still think ScrumPad is for you? Like to hear what your take on PM tool.

Friday, October 2, 2009

How to manage multi-team product development

Managing single team project or product development is easy. All project management tools provide this capability. However, things start to look different when we start to manage projects that spans multiple teams. Some tools do not support this scenario, and others do it through project hierarchy. In ScrumPad, it is as easy as managing single team project. However, the terminology may come in the way to understand it.

Before I explain how we do it using ScrumPad, I need to introduce a few concepts as they are applied in ScrumPad. First is the project. A project is implemented as a means to manage a single team development work. So, a project is associated with a team and a product backlog. The team creates a sprint backlog from the product backlog to manage work in sprints (i.e. iteration). Second is the portfolio. A portfolio is a set of related projects. A portfolio may have its own (product) backlog. You can access a portfolio if you have access to all projects as a product owner. A portfolio is a way to track and manage related projects. Projects within a portfolio share same tags so that you can track progress at the portfolio level. We do not like hierarchical association of projects. We think it unnecessarily complicates things. With non-hierarchical setup, we can easily move between single team project to multiple team program.

Multiple team product development. It is recommended to use a single product backlog for multi-team development. However, it is not required in ScrumPad. You could keep separate backlog for each team. In that case, it will be just like managing multiple single-team projects. If you prefer to manage multiple teams from a single backlog, you would need to setup a portfolio in ScrumPad. You would use the portfolio backlog as the single product backlog for all your teams. First you would need to setup a project for each team. Then you would create a portfolio from "backlog > portfolio" menu and add the projects to the portfolio. If you already have a backlog before using ScrumPad, you can easily import your initial product backlog into your portfolio backlog in ScrumPad from "backlog > import." If you are just starting your project, you can start adding stories to the portfolio backlog as you elaborate requirements. Then you can move stories to project (a,k.a. team) specific product backlogs (a.k.a. team backlog) as you see fit. The teams can then work off its product backlog like any single-team project would.

Program management. If you have a program consisting of multiple related projects, but each project with a single development team, you would setup each projects separately. Then you would define a portfolio representing your program. Add the projects to the portfolio. Now you can track your program across all projects while your projects work independently (without needing a portfolio backlog).

The beauty of the loose coupling between project and portfolio is that you can start small as single team project. As your project grows you can seamlessly move to multi-team development using portfolio.

If you are using the portfolio feature, we would love get your feedback on how we could make it more useful for your needs.

Friday, August 28, 2009

Simple Pricing of ScrumPad Explained

Although our pricing model is simple, it maybe confusing to some of you at first. This is because we are so used to seeing the traditional SaaS pricing plans that we don't even think about better alternatives. Before I explain our pricing model, let's see what a traditional SaaS pricing model looks like.

Traditional SaaS pricing model is usually designed as a matrix of features and levels of plan with progressively higher price. For example, let's see the pricing page of Github, a popular version control system built on top of Git as SaaS. What do you think of the plans? There are 7 different plans differing along 3 attributes- number of projects, amount of disk space, and of course, number of users ("collaborators" as they call them). Here comes the difficulty in choosing what plan is the right plan for me. Hmmm... I have 4 projects and probably will not have more than 5 any time soon. I guess "micro plan" should be good enough for now. Right? Wrong. It would not work because it only allows 1 user and I currently have 12 users. I actually need to get the "large plan." But wait a minute, then I would be overpaying since it is for 25 users and 50 projects. Until I get to that point, which may never happen, I have to bear the pain of overpayment. If you are not confused (and probably a little unhappy since you have to overpay) already, try to determine how much disk-space you would need. The large plan comes with 6 GB disk space. Pretty good, right? What if you start to hit the disk space cap before you ever use up your number of users and projects quota? Man that would add to our pain even more.

Don't get us wrong. Github is a great service. We would have used it if we were not in a pickle to select the right plan for us...:-) Github is not the only one with this problem. This is the case with all SaaS offerings.

Enter our world. ScrumPad is priced as per user per day basis. That is it. So, there is just one data to deal with for you to make the decision. If you think the price per user per day (which is equivalent of $21/month/user) is reasonable for you, you sign up. You never have to worry about disk space, number of projects, bandwidth (data transfer) etc. etc. Now consider our "auto discount" policy. We apply appropriate discounts to your invoices every month based on your average number of users in the month. You don't have to even ask ahead of time. You can now sleep well at night knowing that you are always paying for the exact number of users you currently have. Your number of users can grow and shrink on projects. You do not have to upgrade to add more users, and downgrade when you don't need them. With traditional SaaS pricing, you could end up paying more just because you forgot to downgrade.

Additionally, we put ourselves on the line by invoicing you at the end of the month (unlike everybody else). Not only that, we do not automatically charge your credit card (in fact, we do not even take your credit card information. That is handled by Amazon). Instead, we ask you to explicitly pay us every month. If you are not happy with our service in any month, we allow you to ask for waiver. This is because we want you to use it every day. We want you to actively help us shape our service that you love to use everyday. Not just pay and forget about it. We want you to pay us for the right reason, not because you prepaid us.

Finally, we plan to continue to bring to you more and more value added features at the same price.

We would love to hear from you what you think about our pricing model and policy.

Monday, August 24, 2009

ScrumPad affiliate program is live

We are excited to announce that our affiliate program is now live. This is our way to share the success with our ScrumPad community. If you are using ScrumPad and or have reviewed ScrumPad and think it is a tool that others should take a look and use, we encourage you to become our affiliate and start spreading the words for ScrumPad.

We wanted to make it simple. Anyone, individual or a company, can signup. When you signup you get an "affiliate id." After signup, just start referring people to ScrumPad, and let us take care of the rest- from keeping track of who you referred, and how much your refferal bonus is, to automatically paying you when it is due. It is that simple.

When you refer someone to signup for ScrumPad, and if they put your affiliate code in during signup, we credit you for that referral. You just need to make sure they put your affiliate code as a referrer. Alternatively, you could download our "affiliate badge" that you can put on your site(s). Anyone clicking through your site to ScrumPad and eventually signs up, your affiliate id gets automatically populated and you get credit for that new user of ScrumPad.

We have a very strong reward program for our affiliates. You get 50% of the first month's subscription fees paid by your referred client, and continue to earn 5% of subsequent monthly subscription fees for as long as they use ScrumPad. Isn't that cool or what?

We pay out your earned referral bonus at the end of every month when you accrue $100 or more. The only condition is that you have to have an account with Amazon. We process payments through Amazon FPS (Flexible Payment System).

You can check your affiliate account balance anytime by logging into you account as an affiliate from our site.

We hope you like our affiliate program and join.

Sunday, August 9, 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?

Wednesday, July 29, 2009

Portfolio view in ScrumPad

We have recently added a portfolio view in ScrumPad. A portfolio in ScrumPad is a group of related projects. Traditionally these projects are managed under a program. From that perspective, "a portfolio" is the same as "a program." With current implementation, you can only view backlogs side by side for projects that you are a product owner on. You would still need to separately manage each backlog.

Our ultimate goal is to allow driving multiple projects from a single backlog. This is the case with large projects where multiple teams work on a single integrated product. The best practice is to maintain a single product backlog. We have been brainstorming about how to support this while maintaining a flat structure among projects. We like to avoid hierarchical structure as much as we can. After a lot of white boarding, we came up with a solution that supports our goal of keeping the flat structure.

Now we are working on expanding the portfolio view to support the following features:
  • Move stories from one project (product) backlog to another project backlog
  • Manage multiple project backlogs from a single integrated portfolio backlog
  • Import/Export portfolio backlog
Although we have solved for the architecture, we are faced with design challenges. For example,
  • What do we do with tags when moving a story from backlog to another since tags are backlog/project specific?
  • What do we do with associated message threads, bugs, and impediments?
  • What do we do if the story is already scheduled to a sprint and a release since sprints and releases are project specific?
  • What if the story is assigned to a person who is not a member of the other project (team), which is most likely be the case.
  • Should we allow a story "in progress" to be moved to another project?
  • How do we integrate priorities across multiple projects into a single portfolio view?
As you can see a simple action of moving a story from a backlog to another is not so simple anymore. Our design goals are:
  • No workarounds
  • Less reworks
  • Simple yet robust solutions
Luckily we have optimum solutions to these challenges...:-)

We are pretty excited about the portfolio management in ScrumPad.

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?

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 5, 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?

Sunday, February 1, 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.