Visit the forum instructions to learn how to post to the forum, enable email notifications, subscribe to a category to receive emails when there are new discussions (like a mailing list), bookmark discussions and to see other tips to get the most out of our forum!
Response to "Agile Development"
  • I had to create a response here because it is impossible to respond to the actual post.  In a system that depends on incremental input from volunteers, it seems odd to restrict access, particularly because at the heart of that action is an assumption that the average nonmember contribution will not have value.

    I was looking at the agile system mentioned on the forum and discussed here.

    If we read the Manifesto of Agile Development, it think it clarifies the need for more discussion.  I will post it below, I think it is important to note that this is designed for the creation of software, not hardware.

    We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:
    Individuals and interactions over processes and tools
    Working software over comprehensive documentation
    Customer collaboration over contract negotiation
    Responding to change over following a plan
    That is, while there is value in the items on the right, we value the items on the left more.

    The OSE system is aimed ultimately at individuals, but OSE needs to be more concerned with processes and tools.  A concern with an individual will produce a project that an individual can use, we need one that anyone can reproduce, in order for people to develop, understand and adapt a project, it needs to be something geared towards the tool/process itself.  That brings me to my second point, the express concern of Agile development is a single useable end product.  If that was the goal of OSE, then we would be done with several projects already, because they are built.  However, the projects are ongoing because one of the most important elements of OSE is the comprehensive documentation, which will allow people to build/modify the GVCS.  The third point seems moot in this discussion and the fourth is a mixed bag.

    Just from reading the Agile Manifesto it seems to me that the system is contradictory rather than complimentary.

    Can someone show me how I am misunderstanding this?

  • 13 Comments sorted by
  • Agile is really a frame of mind, ARGH (I like that nickname - it's so expressive!).  It means being open to change and responding quickly and with flexibility.  While I would agree that certain specific agile processes for software development don't quite work, I think we can adapt it to meet our needs.  We might even be at the forefront of exploring how agile techniques might be applied to OS hardware. 

    I also agree that documentation is one of our main deliverables, and that sets us apart from software development.  See my post to the Collaboration forum

    Regarding restricted access, this is the start of a new OSE policy to create special forums restricted to contributors of an OSE project.  While they are visible to all, only team members are allowed to post to it.  It's intended to keep the conversation focused on project needs, while letting the larger community have visibility into what's going on.  Your response to post here is exactly right.  This is the right place for it.

    - Mark

  • I am skeptical about this fear of "sidetracking" a discussion (which is why I will not apologize for not mentioning agile development).  Anyone is free to skip a comment if they so wish.  It indicates a lack of respect for the readers as much as the commenters, like assuming they get distracted too easily from what matters (which may be true for a lot of people, but then we just need better people).

     From what little I have seen of open source software projects, they do not seem to restrict access to their developer forums.  They do post a thing at the top to ask people to respect that tech support etc questions are not welcome which is fine.  Why should it be so different here?   The steam engine forum, for example, a project that is fortunately moving along a lot faster than the others (and not by itself, thanks MJN and others), does not seem to get any noise in the forum.  Why could ARGH's answer not be put on the original thread?
  • One good reason that those forums are closed is that design by committee or decisions by committee is a very painful and slow thing, and in general isn't effective. I've seen this process first hand. Here, we clearly know who the people are who are responsible for making the decisions, and who is accountable if things don't go well. At some point a decision has to be made and everyone has to accept it, and we move forward to either success or corrective action. A clear decision, for either agile or traditional processes, is much better than an unclear ambiguous decision.

    General feedback in a separate forum is a perfectly acceptable and appropriate to give input as things develop.

    Previously I also questioned this system in a separate thread, and while I agree with privileged project forums, I think the individual tools should have open forums. For example, there should be an open "Steam Engine" forum that anyone can post in about steam engines. There should be a privileged child forum "2011 OSE Steam Engine" for the specific implementation of "Steam Engine".

    Not only do restricted forums restrict interference from the "bottom" but also from the "top". For example, there are probably some forums even Marcin himself shouldn't have access to. If he isn't actively working on the project, yet wants to occasionally pop in and make decisions, not only is the organizational structure not much of a structure, but his decisions will likely not be the as informed as the team which is dedicated to the project. If he has valuable feedback from experience in another project which he wants to loop to the team there should be a system to do that other than breaking the structure so that anyone with such feedback can give it in the same way.

    (If anyone questions that last paragraph, saying it isn't an "agile" approach, then I'd respond back that the whole closed forum thing isn't agile. As my post states, I'm not saying closed forums are bad, but we should clearly understand what they mean and what they don't mean.)
  • "Agile does require a shift in perspective. It doesn't happen overnight, but I'm not here to debate it; it's the methodology Marcin has adapted, and we all need to learn more about it and how to apply it."

    End of discussion.
  • Oh, hardly the end of the discussion, ARGH.  Even agile development has many flavors and nuances.  There is room for stylistic differences, IMO.  There is a saying in the OS Software world:  "Working code trumps all talk."  We might rephrase that as, "A working machine is what matters, not how we got there."  As long as people can understand what we've done and replicate it, we've done our job.

    - Mark

  • Well if you say so, Jason, but it smells more like a convenient way for the leadership to ignore others to me... But I'll drop it for now.

    MJN, remember people need to be able to pick up the development process too where it was left off.  Which means they should have access to the prior work.  I think it would be backwards to assume the machines produced by OSE at full product release are "done".  They will always be evolving, always.  Unlike in software you can't take a part out or change something and test it as easily, if it turns out that is something that was added for a good reason you may be in for a surprise months later and you would have a hard time "patching" the hardware. 
  • @jason
    >  MJN, remember people need to be able to pick up the development process
    too where it was left off.  Which means they should have access to the
    prior work.

    Of course.  That's the whole reason for keeping the work in public places like the wiki, forums, and Pivotal.

    >  I think it would be backwards to assume the machines produced by OSE at
    full product release are "done".  They will always be evolving, always.

    I agree with that, Jason.  We WANT them to evolve, improve, diverge, etc.  The more people tinker with the machines, the better off we all are - as long as people make their results known.

    >  Unlike in software you can't take a part out or change something and
    test it as easily, if it turns out that is something that was added for a
    good reason you may be in for a surprise months later and you would
    have a hard time "patching" the hardware.

    It isn't always that easy in software, either, but I take your point.  Still, modularity is something we are striving to design into the tools and machines.  To give you an example from my project, the pins that cause the valves to open at the end of the steam cycle are threaded on one end and screw into the piston head.  This is so that they can be replaced with pins that are slightly longer or shorter - since this affects the amount of time that steam is admitted to the cylinder.

    - Mark
  • mjn,

    You are responding to gregor's post not mine.
  • Oops.  Sorry. :D

  • Do you mean Agile methodology is contradictory to OSE?
  • Vote Up0Vote Down
    April 2013
    @jesspinto,  no, I wouldn't say that Agile development techniques are contradictory to OSE.  However, I think that Agile is difficult to implement for hardware development.  It can be hard enough to do it for software, but hardware presents even more challenges (largely due to the amount of time needed in fabrication).  OSE proposed applying Agile techniques to the development of an Open Source Car.  WikiSpeed was retained to do this, led by Joe Justice.  Well, a year has gone by.  Where is the car?  Where is the design?  Where is ANY documentation?  While it may be possible to use an Agile approach to building open source hardware, OSE's experiences to date have not been positive, IMO.

  • @mjn: sorry to tell you, but jesspinto is just a spammer..
  • I agree with Mark (mjn) Where is the car developed by WikiSpeed? Where is the complete technical documentation to build it. Wikispeed once in 2012 has published a very incomplete 3D CAD model. I've checked it a bit and found it poor and with design flaws. The turning radius of that car would be very large, not suitable for use in the city. The wheel hubs are designed in a matter that would make fabrication in industry difficult and expensive - for DIY impossible to fabricate. Sorry, but what Wikispeed has shown yet doesn't look promising.

    @jesspinto I don't see that Agile principles are really adapted to open source hardware. Availability of good and complete documentation is of utmost importance for hardware. No one benefits from an open source machine that works exceptionally good, but can't be replicated due to missing or incorrect technical documentation. And response to change instead of following a plan is prohibitive with large hardware components - too high expenses for materials and labour + machine tools to fabricate them. Mike


Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!

Login with Facebook Sign In with Google Sign In with OpenID Sign In with Twitter

In this Discussion