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.

Training the Software Requirements Engineer

What are different type of training required for a Software Requirement Engineer?

The correct answer is, it depends. Software requirements training should fit with the type of project management used by your organization.

One type of training you don't need

Many people think a software requirements engineer should thoroughly understand programming and software engineering. Obviously, you should know something about the software engineering discipline, but knowing too much can destroy your ability to write good requirements. This happens for two reasons.

First, good requirements should ignore the technology (such as which platform or language is used). This is because requirements should not dictate the solution; they should only define the problem to be solved. Devoting too much study to the technology will bias a requirements analyst toward particular solutions. This makes consideration of alternate solutions more difficult for the design engineers.

Second, requirements elicitation is an art as much as a discipline. Managing stakeholders, conducting meetings, choosing elicitation methods, and choosing methods for representing information require strong skills in psychology and communication. Putting all your energy into learning programming languages and tricks will cost you on the human side. It would be as great a mistake as putting all your energy into market research. You need to know enough about programming to win the respect of the designers and to communicate with them, but your job is to build a bridge between the customer and the designer.

What should I wear? Well... where are you going?

Organizations that work with large systems that integrate multiple technologies tend to follow traditional Project Management and Systems Engineering methods. They use some variation of the Waterfall model, such as the V model.

For a high-level understanding of Systems Engineering requirements methods, I recommend starting with INCOSE's (International Council on Systems Engineering) Systems Engineering Body of Knowledge (SEBOK) and using the SEBOK as a guide to subjects for study. Also consider studying Model-Based Systems Engineering, one subset of traditional methods, and SysML, the modeling language used for MBSE.

Organizations that work primarily with software tend to follow Agile project management methods. In Agile environments, requirements engineers tend to go by the title Business Analyst. I recommend starting with the IIBA's (International Institute for Business Analysis) Business Analysis Body of Knowledge (BABOK) and using the BABOK as a guide to subjects for study.

Agile is a set of principles and not an actual method. I have asked for a recommendation for a book that describes the different methods (such as Scrum and Kanban) but have been told no such book exists; for each Agile method, you need to find a different book.

The requirements methods differ considerably between traditional and Agile. Traditional methods nail down requirements and then negotiate schedule and cost. Agile nails down schedule and cost and then negotiates, prioritizes, re-prioritizes, and drops requirements.

The two methods do share some of the same tools. I suggest studying Unified Modeling Language (UML). UML is not a language, but a set of graphical methods for defining requirements. The most commonly recommended book on software requirements is Software Requirements, 3rd edition, by Karl E Wiegers and Joy Beatty.

Agile, Waterfall, and PMI Project Differences

I've been asking about the differences between Agile projects and traditional project management.  Many explanations err by answering the question only from a software or Information Systems perspective.  While Agile primarily appears in the software industry, the different approaches appear in many industries and product areas.

Since the Project Management Institute (PMI) offers both Project Management Professional (PMP)^® and PMI Agile Certified Practitioner (PMI-ACP)^® certifications, it would seem that Agile contrasts against traditional project management. 

However, it would be more instructive to contrast the Agile approach against the "traditional waterfall approach" of Systems Engineering.  (Refer to the International Counsel on Systems Engineering (INCOSE) for details.)

Agile uses a highly iterative approach that works better when requirements are vague and must be defined over the course of the project.  It is more appropriate for, as an example, the next set of security updates to Windows or the next year's model of the Ford Mustang.

The waterfall approach assumes progressive or phased elaboration of a fixed set of requirements that can be defined, validated, and turned into a design architecture or solution, from top to bottom.

However, Agile methods can still be used for portions of the system, particularly peripheral functions of the software. It is more appropriate for, as an example, the core of MS Project 2015 or a new hybrid squirrel-electric vehicle.

 

Copyright 2013, Richard Wheeler -- Permission granted for non-profit or personal use with a link to this post.

IT Metrics and Productivity Institute (ITMPI) Premium membership gives members free access to 400 PDU-accredited webinar recordings and waives the PDU processing fees. The library is growing at about 100 webinars per year. Check it out: http://mbsy.co/dPHm?s=e

Project Management Career Path

In terms of study, what path should one take to become a project manager?

First, unless you have several years of project management work experience, I would suggest obtaining the Project Management Institute's (PMI's) Certified Associate Project Manager (CAPM) certification. After that, study the qualifications for the Project Management Professional (PMP) certification and create a plan based on those qualifications. The plan should include studying PMI's Project Management Body of Knowledge (PMBOK) Guide and added studies based on the PMBOK Guide's process knowledge areas.

Second, familiarize yourself with the International Counsel on Systems Engineering (INCOSE) Systems Engineering Body of Knowledge (SEBOK). After achieving PMP certification, pursue INCOSE's certifications. PMI certification will give you a top-down perspective across all departments whereas INCOSE's certifications will give you a bottom-up understanding of the engineering processes and products.

Studying these two knowledge areas in this order should provide a faster path, on paper, to project management and beyond. However, if you would prefer a career path leading to a Chief Engineer title, you might reverse the order. Pursing Engineering in Training (EIT) and then Professional Engineer (PE) certifications would be valuable on the technical career path, too.

Third, study people, develop lots of relationships (focus on the personal aspects and what you can do for them, not on what you can get out of them), and find at least one mentor other than your supervisor. These are critical.