-Open Source development depends a lot on community, their feedback,

their suggestions, their reviews and their enthusiasm.

-For an open source development project, the community itself is the first customer.

-Product release for the community provides a good starting point to assess

how the product will be accepted in the market.

-This is very beneficial as it gives the software development team an edge over

its competitors as it gets the pulse of the customer

-In many ways the open source development has the culture similar to that of

an Agile enterprise.

-The principles guiding open source development are similar to Agile principles

-The session presents views on above as well as how open source development projects employ agile for

both the community development and for their own licensed version of the software.

 
2 favorite thumb_down thumb_up 4 comments visibility_off  Remove from Watchlist visibility  Add to Watchlist
 

Outline/structure of the Session

-A word about open source development

    -upstream and downstream development

How Agile applies to open source

    -Engagement between community and developers

    -role splitting and clarity

    -release distribution

    -quality of delivered software

    -agile eco-system in open source development

    -support

-Conclusion

Learning Outcome

-Agile vis-a-vis Open Source:

    - how open source uses agile methodology?

    - what new open source development offers to Agile

-Engagement Model:

    -engagement between product teams and user community

    -impact on community software

    -impact on quality and delivery of licensed software

    -how does the user community benefit from this enagagement

-ROI for customers: how do users/customers benefit by using open source software

-Support: how does support mechanism work?

-Outlook: Why open source is catching up faster?

Target Audience

All

schedule Submitted 3 years ago

Comments Subscribe to Comments

comment Comment on this Proposal
  • Joel Tosi
    By Joel Tosi  ~  3 years ago
    reply Reply

    Hi Sharad,

      I worked for a rather large, open source company for a few years and some of the items you bring up are very relevant and true - almost an advantage - to open source communities.  However, there is also a challenge with open source around going where the community wants to go versus what is best for the project.  What are your thoughts on that?

    Best,

    Joel

    • Sharad Julka
      By Sharad Julka  ~  3 years ago
      reply Reply

      Hi Joel,

      A couple of natural questions then are: What is best for the project? And who decides that? 

      I believe the community decides what is best for the project. Primary reason for the same is that they are not only the contributors but also the primary users. They best know what the project was envisioned and designed for. 

      I can agree that for some of the open source projects, there has been a loud and concerned voice regarding the project not going where it should go. However, it has been found that this voice comes from a small but more influential and corporate group who have recently found large interest in the project.

      Even if we, for a minute, agree that community is not working in the best interest of the project, I believe for the sake of the project, some actions can definitely be taken. I have seen organizations taking lot of interest in the community development by directing many of their resources towards contributing to community development in addition to contributing to their own version of the open source project. And then, there is not one organization that does it, there are a whole lot of it. So, the development group does not remain purely of community but also of large corporates who directly or indirectly influence the roadmap of the project. I think it demands a very balanced act to be able to get the best out of the community without over-influencing it. Best is to remain as close as possible to the original idea and purpose why this project started and what was the vision. 

      Well, these are just my thoughts. I would be glad to hear from you since you have seen more.

       

      Sharad

  • Sachin goel
    By Sachin goel  ~  3 years ago
    reply Reply

    Hi Sharad,

    Thanks for the submission. Two specific areas needing your inputs for the proposal:

    1) The title "Agile For Open Source Development Project " makes me believe that we will be talking how to use Agile in Open source development. But you also have put a comment like "In many ways the open source development has the culture similar to that of an Agile enterprise." making me think we can learn some of new agile practices from such development.

    It will help if you can clarify the focus of this talk. Agile in Open Source Dev (OR) Learning from Open Source Dev to improve agile practices

    2) A lot of content, it seems, is around open source software dev and its dynamics, which could be of genuine interest. Though I am not sure if Agile Conference is the right forum.

    Thanks

    Sachin

    • Sharad Julka
      By Sharad Julka  ~  3 years ago
      reply Reply

      Hello Sachin,

      1. Regarding your first point, yes, it is a mix of both and that is why the title "Agile For Open Source Development". There is definitely something that open source can offer to agile as it has lot to do with the community. The community eco-system is self-driven and self-managed and I believe that is one of the great movers for a successful and widely-accepted product. I agree there are concerns regarding support, and that is exactly what I will be touching on.

      2. I have tried to keep as much focus on agile with open source. I have removed the word "development" from the title to not give an impression that I will taking any deep dive into open source development per se. I have also modified all three sections to match the title.

      Undoubtedly, the actual content will have answers, however, please feel free to revert if you feel the proposal still lacks clarity.


  • 45 mins
    Demonstration
    Beginner

    Can you maintain agile engineering practices with a distributed team?

    Johannes is the Oslo based Chief Scientist for the Sri Lanka based company Exilesoft. In order to promote agile engineering practices, he uses remote pair programming to connect with teams halfway across the world.

    In this talk, we will go through a practical approach for remote pair programming adopted for high-latency situations. We will demonstrate remote pair programming with a live example and we will discuss the advantages and usages of the approach. We will also cover the practical parts of remote pair programming, such as tools and setup.

    After seeing this talk, the audience should be able to remotely pair with members of their distributed team. They will also get a lot of tips on how to use pair programming effectively in both local and remote settings.

  • Liked Nikhil Joshi
    keyboard_arrow_down

    Build - Measure - Learn : Without spending a fortune

    20 mins
    Experience Report
    Beginner

    At times we have great product ideas but the biggest barrier to entry lies in answering few questions such as:

    - How do I define and validate Problem hypothesis, Solution hypothesis and Underlying assumptions?

    - How do I quickly setup a platform for people to register their interest?

    - What will keep the potential customers engaged, excited until the first release (or beta) is out?

    - How do I get feedback from the early adopters?

    - And eventually when I have answers to some of these questions, how do I make a decision to persevere or pivot?

    If you've faced a challenge while answering any of these questions while building/validating your product idea, this session is for you. We'll look at tools and techniques to validate the product hypothesis early-on without spending months or fortunes. We'll also look at a case study to highlight how some of these tools, techniques helped us validate our product idea.

  • Liked Sharad Julka
    keyboard_arrow_down

    Performance Appraisal For An Agile Team

    45 mins
    Experience Report
    Intermediate
    Our affection with Bell Curve has been for long. 
    -It is (one of) the most "natural" scheme(s) of evaluating
    and judging performance of an employee in an enterprise.
    -It provides a fair view of the employee performance level
    of all employees to the management.
    -However, in an Agile world, where everyone in the team is expected
    to exercise equal responsibility and accountability,
    does Bell Curve PMS act as a hindrance?
    -Does it motivate a few and demotivate others?
    -Is it the right tool to use?
    -Is it used in the right manner?
    -Does it affect the performance of a highly productive and efficient team?
    -Do we have a choice?
  • Liked Savita Pahuja
    keyboard_arrow_down

    Battlefield Agility

    Savita Pahuja
    Savita Pahuja
    Agile Consultant
    Palo-IT
    schedule 3 years ago
    Sold Out!
    45 mins
    Workshop
    Intermediate

    Battlefield Agility® is a quest to make our deliveries better, more collaborative, faster and effective. It relies on age old principle from the Army to provide a holistic view of the problem landscape which a project team needs to solve and be able to succeed in this, through small collaborative groups working in coordination to achieve the bigger goals.

    Battlefield Agility® derives from the Agile manifesto and principles and adds to it the key ingredient of individual wisdom to create a plan for a team which will help it succeed in successful deliveries . This is a goal based approach to increase MVP and ROI.

    The purpose of this method is to make team members more focused about their work, equal distribution of work in the team and increase productivity.

    Battlefield Agility enumerates the mechanisms of planning, better field view to all team members, ease of multitasking, reduce task switching.

    Key benefits of Battlefield Agility® 

    • A focused approach to software development as development proceeds through small battles to be won
    • Reduced multitasking and better efficiency of team members
    • Faster deliveries as the work is divided to right sized battles to be won
    • Parallel efforts by team members ensure the time to market is significantly lesser
    • Less process overhead as the collaboration is real time and more time is spent on the ground than on meetings
    • Small teams ensure close camaraderie and collaboration among team member
    • The team can even work on disparate work areas ( if required) in order to make best us of their expertise