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!

I'd like each member on this project to familiar themselves with the basics of agile development. Agile is, after all, the general approach that Marcin has advocated, so let's all try to get on the same page!

Agile development requires a fundamental shift in thinking from traditional project management approaches, which involve formalized processes, lots of documentation before action, and long development cycles. Elements of this traditional approach pervade some of the discussions in the public forums and in the policies on the wiki.

And also, there's no better way to learn about agile development than to use it! So let's use this particular forum for general discussions, but get accustomed to using Pivotal for user story-specific discussion.

While I admit to being "old school" when it comes to project management, I would like to point out something. To a large extent, documentation IS the deliverable in these projects. This collaboration project is extremely different than most of the OSE projects since it involves the creation of an abstract thing we call software. I'm not saying that we can't apply agile techniques to hardware development, but there are differences between hardware development and software development.

Consider the 12 principles laid out in the wikipedia article:Customer satisfaction by rapid delivery of useful software

Who is the customer in an OSE project? The ultimate customer - the person who builds a GVCS tool from our plans - is really present in the process at this time. Marcin and the other folks at FeF come the closest.

Welcome changing requirements, even late in development

Being flexible to changing requirements will be needed. Designs will change has we get deeper in to the development of GVCS technologies, but it does sorta imply that there are requirements known in advance. There needs to be at least some guiding requirements before the process can start.

Working software is delivered frequently (weeks rather than months)

Let's face it - no matter how much we'd like it to be otherwise, we are not going to be cranking out new hardware prototypes every week or even every month. Interestingly, Marcin and I had a discussion on this topic. I put forth the notion that developing the Steam Engine would likely be an iterative process involving several actual prototypes. He rejected that in favor of trying to "get it right" the first time. That shaped my approach to the project and I shifted a lot more attention into design review, up front drawings, etc.

Working software is the principal measure of progress

In an OSE hardward project, we will need two measures of progress: working documentation (ie, free of bugs and problems) and working prototypes (which can take a significant time to build).

Sustainable development, able to maintain a constant pace

This is something we need to be better at. OSE, at this time, is very "bursty" as people shift from thinking to designing to prototyping to production. Part of this has to do with Marcin being central to most of the active OSE projects. His time as become very precious and he slices himself rather thin. Still, things are happening.

Close, daily co-operation between business people and developers

What business people? Most of us are volunteers who have a limited amount of time to contribute to OSE development efforts.

Face-to-face conversation is the best form of communication (co-location)

While I agree that F2F is better, most OSE projects will be globally distributed. Geography cannot be overcome, therefore we'll need to adapt to the challenges it engenders (such as time zone differences).

Projects are built around motivated individuals, who should be trusted

Generally, the motivation is there, but work is required to sustain it. I've been involved in enough OS and volunteer projects to know that the project leader/manager has the role of a cheerleader urging the troops onward. The matter of trust is something that needs to be considered as well. Generally, trust can be assumed based on some initial assessment of capability. Managing broken trust is a delicate thing in volunteer organizations. If you are too hard on people, word gets around and qualified volunteers go elsewhere. If too soft, things don't get done. It is a balancing act.

Continuous attention to technical excellence and good design

While some effort has been made to outline general OSE standards, they are not explicit enough to measure a project by. Consider the lack of documentation standards, for example.

Simplicity

Simplicity will need to be managed into OSE projects through functional decomposition. While some GVCS tools are quite simple, most are complicated and have dangerous aspects to them.

Self-organizing teams

We have the start of this but we need to have guidance on how to go about organizing. I have made some attempts to describe how this should be done. More work is needed.

Regular adaptation to changing circumstances

I think people will deal with this just fine. Most OS contributors are comfortable with change, in my experience.

In sum, Vann, we need to give some thought to how agile development techniques apply to OS hardware. It is a mistake to think that techniques that work well for software will work equally well for hardware. I think, to some extent, we are charting new ground here. Given that this particular project is focused on the tools that will foster and guide OSE projects, we should consider the bigger picture. This includes an examination of the OSE project development process.

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.

We are our own customers/stakeholders/business people, at first. Any deliverable, including documentation, is accommodated -- there's no reason that docs can only be produced via waterfall methods.

Changing requirements and short development cycles are also there in hardware world: Marcin went through one physical prototype of a PowerCube and several design prototypes in just the two weeks that I was there! Trust can be built up over time as people earn merit, rather than say when hiring (via interviews). Really, all these objections seem to stem from unfamiliarity with agile development.

I'm not saying, however, that no thought has to be put into it, but I encourage you to start with an open mind, not primarily a skeptical one. Start putting tasks into your own Pivotal project. Start with the simplest user story possible, like "build a steam engine", and iteratively refine it and break it down: "it should produce 3kw of power ecause that's what's required to drive our tools..." "it should be made from steel...because we can get steel locally cheap", or whatever. then break it down further, etc etc, all the requirements of documenting, promoting it... and when you work on the project, and you'll soon find how deceptively powerful this style of thinking is, with a lot less overhead spent planning and following fixed process.

these processes that are being written haven't been followed yet. even marcin has noted he didn't follow his own processes. requirements (user stories/requests) are fine, but trying to connect a bunch of arrows between them is not adaptive. this is all a learning process for each of us. if we allow the process to be dynamic, and let pivotal enforce the minimal process of making and fuliflling requests, we'll test this style and learn firsthand about agile development, and all be better informed to comment on it.

I think you're being a bit unfair, Vann. You seem to be forming the opinion that I'm against an agile approach - I'm not. You also imply that don't know that much about it - also not completely true as I've worked on software development efforts that used SCRUM and XP. You also suggest that I'm using a waterfall approach to the steam engine project - also not really the case since I'm pretty much the only one working on it. As such, I feel free to tackle the work in the order that makes sense to me. Methodology is largely there to coordinate the actions of a team. I have used functional decomposition techniques to break the work down before tackling it. It is already iterative in the sense that new information is coming to light, changing the requirements, the design, and the fabrication plans. If my style doesn't quite match yours, I personally don't think that's a problem. Work has gotten done. It's moving towards prototyping at a steady pace - which is about all OSE can ask of anyone at this stage.

Regarding this project, since you are the project manager, I defer to your management style. I believe I'm flexible enough to adapt to it. If not, then I will bow out with no complaints or feelings hurt.

i'm certainly not attempting to be unfair! it just didn't seem like most of the topics you brought up were problems of a particular mgmt approach. but it's good to hear you have experience with adaptive methods, and use such methods yourself. but to have a conversation, we have to listen and respond to each other. i certainly regret that my response caused you take umbrage; that was certainly not my intent. but i didn't hear you address any particular response i made to your points, so i don't know how to move forward. it's fine by me though if you don't want to pursue those threads of the conversation.

my main intention with this is to get people away from writing about processes (with the equivalent of diagrammatic workflows with arrows and the like).

i think the OSE specs need to be articulated into a clear set of user stories/requests and standards, but also separated from any particular project management style, weather waterfall or adaptive or inbetween. this would allow some teams to use highly predictive styles (like PLM software similar to Aras, even), and others to use highly adaptive styles (like that encouraged by Pivotal) -- even though Marcin has adopted Pivotal for now. i just think it'd be clearer overall. would you agree that would be helpful?

I've used Spring and several UI frameworks (Struts, JSF, JSP, Velocity, etc.). I have also designed and built at least one major Java framework myself (three years of labor and counting). Recently, I've been getting back into PHP programming, some some of the LAMP frameworks might be coming into play.