Welcome

What works and what doesn't work in software development? For the first 10 years or so of my career, we followed a strict waterfall development model. Then in 2008 we started switching to an agile development model. In 2011 we added DevOps principles and practices. Our product team has also become increasingly global. This blog is about our successes and failures, and what we've learned along the way.



The postings on this site are my own and don't necessarily represent IBM's positions, strategies or opinions. The comments may not represent my opinions, and certainly do not represent IBM in any way.

Wednesday, March 17, 2010

Open Source Software

Thanks to Husain for this topic suggestion...
"What Software Development Methodology can best fit in delivering an open Source Software??? After doing a little research I found no better than the Agile method!!"

Open Source (and Community Source) software is special, in that much of it is developed in tiny pieces by people working independently. It does lend itself to agile development, in that the requirements are not all collected in advance. Open source development cannot be done in a waterfall fashion, where all of the design for a release is done at one time, then all of the development, then all of the testing.

The one open source project I worked on used a project backlog, where people would pick up the next high-priority work item (story) that interested them. Someone would write a bit of code, test it, document it if needed, and submit it. Then the changes were approved and integrated by the project owner, and released to the public within a few weeks. So, adding a new feature/story was like a mini-sprint. However, the project did not use time-boxed iterations with fixed start and end dates. Each person was on their own schedule. It was very agile.

I think this highlights the fact that Agile software development methodologies are not one-size-fits-all. What works for a typical open source project would not work for my current project.

Our product consists of several components that depend upon each other. To implement my new feature, I may have to ask someone from another component team to write some new code for me. And someone else may use the new code I'm writing in their component. Because we are adding major new features across the board, we usually need to install the same version of every component, or they will not work together. We also need to plan some features a few months in advance: component A will implement the first piece, then component B will use that new feature and implement the second piece, and then component C will use features from A and B to implement the third piece. Our customers expect A, B, and C to all work together, so we need some time to stabilize the code and test all of the pieces together. So we have a couple of months at the end of a release where no one is allowed to make any major changes, and only bug fixes go in. We also use this time to test the code on additional platforms, and in different languages. This is less agile, but it's not realistic to expect us to ship a complex product like this without some dedicated time to stabilize everything and clean things up.

I have some stories about a team I know of that calls themselves agile, but really isn't. It's pretty silly what they do, really. More on this later...

2 comments:

  1. Ann,

    I would like to thank you very much for spending the time on writing this post as a favor for me first, and for mentioning my name second.
    That's very kind of you :)

    It hasn't been long time since I started looking for a specific Agile Method fitting that purpose, the Open Source/Community Development way.

    To quote from your post: “I think this highlights the fact that Agile software development methodologies are not one-size-fits-all”.
    That's absolutely true! This is the great thing about Agile, it accepts Method Tailoring. Actually, almost all Agile methods are suitable for method tailoring.

    I found that eXtreme Programming, a.k.a. XP, method “makes the need for method adaptation explicit. One of the fundamental ideas of XP is that no one process fits every project, but rather that practices should be tailored to the needs of individual projects.”

    Choosing a suitable Agile Method can be governed by various factors that should be taken into consideration. Two of which I can mention:

    Team size: small vs large team
    Location: co-located vs distributed team members

    Since XP is the most adaptive/tailorable agile method, the following 2-year old slides explain how XP can be mapped to Open Development:
    http://www.slideshare.net/rgardler/agile-and-open-development

    I noticed that most of the terminologies you've been using are borrowed from the Scrum method, aren't they?

    Great post, Ann!
    Thank you very much, and looking forward to read the story of that team ;)


    Best Regards
    Husain

    ReplyDelete
  2. Husain,

    Yes, we do mostly use Scrum, adapted for a larger team that is not all in one location. We use Rational Team Concert as our project management tool. RTC also uses terms like sprint, story, task, etc.

    After about a year of really using RTC and Scrum, the terms are finally starting to feel natural.

    ReplyDelete