With all of the buzz about Agile, I have to mention that here at INCOSE 2008, I did not hear a single mention of it (except when I asked about it directly!). Actually, that’s not true, at one point I was excited to see a speaker’s slides which referenced applying agile processes as a step in a project. Then he spoke to the slide and I started to suspect he meant agile in the pure definition of the word, to move quickly. At the end, someone asked him the specific question as to whether he meant the agile software methodology and he clarified that he did not. So I left the conference wondering - with all the discussions about processes at a conference like this, why are they not ever speaking about agile?

My first guess - this probably relates to some of the core differences between systems and software engineering. I am going to over simplify this and just say that it is about scale. Systems projects are just a superset of software and hardware projects, integrating and deploying some combination of these. The teams of people deploying systems projects are quite large. And many of the projects discussed here are for government or regulated systems where specification and traceability is necessary. I could see how subsets of systems projects could in fact be developed using agile (pure software components), but I’m not convinced that an entire end-to-end project can. To put this in context, imagine you are building an airplane - a very commonly referenced type of systems engineering projects. Can you see this working using agile?

All skeptism aside, I do think that iterative development most certainly could work well on systems projects, and most people here would not argue that. In fact, I would love it if we could find examples of agile working on systems projects, because the number one feeling I get at systems engineering conferences is a craving for lighter processes.

I decided to do a little research outside the conference walls, and low-and-behold, I found a great article on this exact topic – “Toward Agile Systems Engineering Processes” by Dr. Richard Turner of the Systems and Software Consortium. The article is very well laid out, and I highly recommend reading it. He defines what agile is and what he believes the issue why most systems engineering projects are not agile. For example, he suggests that executives and program managers tend to believe that the teams involved have perfect knowledge about systems we are building, so we can plan them out in advance and work to a perfect execution against a perfect schedule.

He talks to how to the agile concepts can work in systems projects. Here are a few examples summarized from his article:

• Learning based: The traditional V-model implies a one-time trip through, implying one time to re-learn. However, perhaps the model can be re-interpreted to allow multiple iterations through it to fulfill this.
• Customer focus: Typically systems engineering processes do not support multiple interactions with the customer throughout the project (just up front to gather requirements). That said, he references a study indicating the known issues with that on systems projects. Therefore, perhaps processes should be adapted to allow for this, particularly allowing for them to help prioritize requirements throughout projects.
• Short iterations: Iterations are largely unheard of because the V-model is a one-time pass through the development lifecycle. That said, iterations of prototyping through testing could be done in systems engineering in many cases. The issue is in delivering something complete at the end of each iteration. He suggests that this is not as important to the customer in large deployments as is reducing risk, validating requirements, etc. This is a great point to rememember the airplane example! Could we have even a working part of an airplane after 2 weeks? What about even the software to run a subsystem on the aircraft?
• Team ownership: Systems engineering is very process driven, so this one is tricky. Dr. Turner puts the idea out that perhaps allowing the systems engineers to drive it instead of the process to drive them, while more uncomfortable for management, might produce more effective results.

So while he does give some suggestions to adapt systems engineering processes to be more agile, I don’t think this will qualify as purely agile. And frankly if it we tried it, I think I'd be fearful to be in the airplane! But to quote Dr. Turner directly “…other hand, agility is much more a state of mind or philosophical approach than a set of rules that have to be followed regardless of appropriateness.” Using that idea, combined with what I saw at INCOSE 2008, I can see some definite opportunities for improvements for the field systems engineering.