Signing Out from INCOSE 2008

Well, I hate to say it, but my week here at INCOSE 2008 has come to an end. And though I must say goodbye to my INCOSE friends, I'm not headed home quite yet - first I will enjoy a few days in Amsterdam, just up the road from Utrecht.


A few final comments from this side of the pond (some of these are purposefully non-INCOSE related to keep it interesting!):

• After hours of listening to talks about process, I have to say - systems engineering processes are heavy! There are images dancing in my head of things like a project plan circle diagram that even in a 3x3 foot printout, you have to squint to read the tasks. Or there are the matrices that don't even come close to fitting on a page, yet they try to squeeze them in for demonstration of a concept.
• I spoke with some systems engineers who, when I explained what Seilevel does, said things like "Really? Requirements as a job?" or "You have a business around that?" or "I never thought of them as a separate thing, they were just some other task on my project that maybe got done." or my favorite "Why are you at a systems engineering conference then?"
• It's a small world. In a city of more than a million, today I ran into a fellow INCOSE member from San Antonio, TX on my way back from the Rijksmuseum.
• Most all of the presenters like to use words on slides! Seriously, I almost think it must have been in the presentation requirements - "Must have wordy slides". Perhaps I can suggest Beyond Bullet Points.
• I enjoyed reconnecting with my friends from what I like to call "Seilevel Europe", the HOOD Group (and mind you, they would and should probably call us "HOOD Group USA"). We have very similar companies, with similar methodologies, in different parts of the world. If you haven't heard of them, I encourage you to take a look at their work.
• Sadly, Holland just lost in the quarter finals of the Euro 2008. I say sadly because I've actually become quite fond of watching the "Oranje" games (or maybe just the crowds hanging outside of bars).
• I once again was reminded that so many Americans have a tendancy to focus on just us. This is by no means a generalization though. I personally like to intermix with those from other countries, though I'm also quite guilty of speaking American and little else. Anyway, it was frustrating to listen to talks from Americans who would only quote American statistics, or American events, or American disasters. My European friends were quick to point it out for me "Oh another American talk!". Thankfully some of the talks were very different than that though, making me much more proud.
• We should do more peer reviews, but not for the obvious reasons. A systems engineering organization requires team members to be on peer review boards, not so much for improving the quality of the deliverables, but more importantly, to expose the engineers to more projects and ideas that they can then apply to their own projects. Brilliant, I say!
• The field of systems engineering has many many many outstanding success stories, ranging from the Airbus 380 to the ProRail system of the Netherlands. There are lots of great lessons to be learned here that can be applied to much simpler projects. But really, how cool would it be to build a network of thousands of kilometers of rail or to put a new airplane in the air?

Anyway, in a few days, I will return home with many fond memories of the Netherlands and INCOSE 2008.

INCOSE 2008 - Can You Build an Airplane with an Agile Approach?

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?

Airplanes Are Not Software Requirements

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.

Agile Can Work With Complex Systems

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.

Ask, Don't Tell

As you may have surmised from other posts, I'm a daddy. I have an almost-two-year-old little boy who, as his age would suggest, is in the midst of the "terrible twos" (by the way, most people I've talked to about the phenomenon agree that it starts around 18 months and lasts until college). He's extremely strong-willed, and he is also extremely vocal. So, when he doesn't want to leave the kitchen even though you're trying to cook, or empty the dishwasher, or clean up, or unload the groceries, he's very clear about it!

I used to try to instruct him to come out of the kitchen, or come with Daddy, or play with puzzles, in order to get him to do what I want (leave the kitchen), and he simply replies, "NO! NO! NO!" Eventually, I found a surprisingly powerful way to deal with his less-than-helpful single-mindedness, though -- asking questions. If, instead of suggesting an approach, I ask him if he would prefer to read a book or flop on the bed, he usually picks one of the two choices and quickly runs out of the kitchen. If, instead, I had suggested that we do one or the other (or both), it would have been NO-time again. When it's his choice, though, he's happy to oblige.

I've found the same approach to be equally powerful with my requirements work. If I come into a requirements gathering situation and begin telling people how things are going to go/work, I find that I often encounter resistance (stated or unstated). However, if I plan ahead and have several options available in my toolbelt, then I have the ability to ask SMEs how they'd like to work together. They get to be in charge of the decision, even though I've only offered them viable choices to pick from. I realize that this may be a bit deceptive, but I think of it instead as me helping my SMEs make good choices, often in spite of any preconceived notions about requirements work.

It's important to note that, both with my son and with my SMEs, I limit the choices. I don't ask my little boy "What would you like to do?," but instead "Would you like to do X or Y?" Similarly, I don't ask SMEs how they would like to provide their requirements, I ask them "Would it be better to sketch out the existing process on the whiteboard or for me to watch you work through it at your desk?" I don't offer alternatives that I don't think would work (like "playing with knives" for my two-year-old or like "please fill out this use case template for me" with my SMEs), just those I think are solid options for the situation.

It's hard to follow this approach all the time, especially when I'm in a frustrating situation or environment, but when I'm able to take a step back and put the other person in the driver's seat (but only of a car that I think is appropriate), we both win.