The Black Hole of the Agile World: Systems Thinking

Agile fanatics (excuse me: practitioners) love to do things in tiny increments.

That's OK for products where bite-sized deliveries have value, but it's fantasyland for many real-world projects.

Take, for example, the design of a new car. Sure, you can break the car into systems -- chassis, body, safety package, motor, and so on. Waterfall does that, too, but let's consider the airflow over the body. The airflow is affected by the whole assembly. Every part affects the whole. You can't just design a fender in isolation and say, "Looky, looky, I've delivered value!" No, you've delivered an irrelevant piece of scrap.

In any course on Business Analysis, the importance of a unit on Systems Thinking cannot be overemphasized because the Agile world has completely forgotten its value. 

Before the 1990's, there was a role called Systems Engineer.

That title is still around, but the job is not. At least, the job has become a rare grain of wheat a vast field of tares.

A Systems Engineer had many skills of a project manager, a BA, a Systems Thinker, and a cross-disciplinary engineer, all rolled into one.

Along come companies such as Microsoft and Cisco, dropping the qualifying word from titles such as Network Systems Engineer, Software Systems Engineer, and Server Systems Engineer. Suddenly, every engineer, analyst, and administrator is a Systems Engineer. I wish I had a paycheck for every time a recruiter has contacted me with a so-called Systems Engineer job that turned out to be for an IT admin or a software coder.

True Systems Engineering jobs have become needles in a field of haystacks, and systems thinking has almost been forgotten.

Thousands of Systems Engineers lost their jobs due to decimation of the US Defense sector in 2009. (I proud of myself for not pointing out the predictable political element of that.) They still find three strikes against them:

1. Transitioning to a different job category such as Project Management or Business Analysis
2. Getting a foot in the door of a different industry (other than fast food)
3. Living in a job market where all the growth is in part-time service jobs and has gone to low-skilled workers

Hiring managers would do well to consider bringing in experienced cross-disciplinary, systems thinkers. It would not take much training to bring them up to speed in new roles such as PM or BA.

Have you ever thought of a project as a system of people, or a product as a system of technologies? Systems Engineers do that instinctively, and such integrated systems thinking could prevent a lot of headaches for maturing companies.

Now, if you'll pardon me; I need to clean up a spill in aisle five.

Models versus Prototypes

What is the difference between models and prototypes?

Some people are confusing prototypes with models. Most of the examples given in other comments are engineering models (and they are valuable). A prototype is one type of model.

1. Before prototypes, you have engineering models. For example, a wireframe diagram just sits there. It's not a prototype, but it's still valuable. On the other hand, you might have a program with a generic GUI. It might be fully functional, but without the semi-final GUI, it's still not a prototype.

2. A prototype is the first (proto-) thing of its class (-type). Prototypes would include the Beta version of a software product or a widget built in a shop.

3. After the prototype, you have the production model. That's the model you sell in the store, the one you send out samples of, or the one that comes off the assembly line.

Off my soapbox and on to the questions:

1) Does prototyping have to be studied by external institution?

That depends on the product. Suppose you work in IT and designed a SharePoint site for the Engineering department. You will want Engineering to see models and then the prototype in order to identify the refinements that will take your product from "Gets the job done" to "Delights the customer." If your customers are other companies: Yes, you want it to be reviewed by them. And if you are subject to regulation by government agencies and licensing authorities, it's far less expensive to get their approval early than to get it later.

2) What information can we get from prototyping? Does the information we get show us the quality or preference or anything else?

Quality means, "how well the product meets the needs." If showing the prototype to the customer helps ensure that it meets the customer's needs and preferences, then the feedback helps to ensure quality.

For example, before converting Office from drop-down menus to ribbon bars, Microsoft probably let hundreds of users play with it. They would have found out preferences for how many icons to fit in a frame, which functions to place in the ribbon, which functions that were now hidden people would have to go hunting for, and how much they'd have to spend on marketing to convince people to accept the transition.

From a systems perspective, when Microsoft converted Office from the old file types (.doc, .xls, .ppt) to the new formats (.docx, .xlsx, .pptx), they used prototypes to investigate compatibility between programs.

 

For example, could you still import a section of an Excel spreadsheet into PowerPoint? Could you still save a Word document to Open Document Format or RTF files? Will Word and Excel compete for the same memory space and slow down or even crash the computer? Will the new version of MS Access have a reduced startup time?

 

Even after that, Microsoft still puts Beta versions in the hands of thousands of users to find the problems nobody thought to test for.

 

You can't answer such questions with confidence until you build working prototypes to test and experiment with.