In the world of product development, the steps to success defined as a working prototype (within time and budget) has always been a battle. By definition, you will never know the exact path to the goal, making it very hard to peg down the resources needed to hit the target. This has been especially hard in the software world because of the flexibility of the product. Since software is so easily changed, it practically invites the team to tweak it continuously, almost certainly ensuring scope creep. In an effort to make this situation more tractable, a handful of deep thinkers (ca. 2000) put together a manifesto consisting of four values and 12 principles. They referred to this improved product development process as Agile. The four values are worth a deeper look.

The four values of Agile:

Source: Unsplash

• Agile values individuals and interactions over processes and tools
• Agile values working software of comprehensive documentation
• Agile values customer collaboration over contract negotiations
• Agile values responding to change over following a plan

It’s pretty clear from this list that the emphasis is designed around change and frequent interactions. In other words, it matters less what path you followed and more that you were collaborative and delivered working software. This has both desirable and undesirable consequences.

This isn’t a free-for-all program-a-thon, though. This is a structured cycle of events to move the process along. Step one is called “preparation.” At this stage, a list of desired features is developed; this “backlog” of features and the time to complete each one is estimated. Step two is called “sprint planning.” This is an activity in which certain features are selected for the team to focus on during the “sprint.” The third step is the sprint itself, which is a fixed duration task of building the code, usually two weeks. Of course, issues may arise during the sprint that may call for modifications to the sprint plan. At the end of the sprint, working features are demonstrated to the stakeholders and discussions are held to highlight what went well and what did not. The next sprint is planned based on the progress and the feedback and then another sprint is executed. This is repeated until the minimum viable product (MVP) is produced. In the physical world, this would be the first working prototype.

This process was developed in the spring of 2000 and it seems to have accomplished its core objectives: speed up software development and drive projects within the limitation of time and budget. Like all processes there are tradeoffs.

Source: Unsplash

Here are some of the pros:

• Increased flexibility — responding to change
• Improved communication — Individuals and interactions
• Reduced risks — by breaking into sprints and re-assessing as you go.
• Increased customer satisfaction — regular feedback from customers keeps them engaged in the results.

And here are some of the cons:

• Limited control — Because agile development is more flexible, placing interactions over tools, there can be conflicts in how to accomplish some of the goals.
• Lack of documentation — With less emphasis on documentation, there is some increased risk. Documentation is useful in upgrading software performance and establishing the work flow within the program.
• High level of collaboration — This requires additional effort in communication. Lines of communication need to be frequent and who needs what information should be clear. Remote workers could compound this issue.
• Frequent customer input can lead to scope creep — It’s easy to agree to something in a customer meeting and then find out that the implementation is more difficult than imagined.

Not so implicit in the four values framework are other common pitfalls that have gained notoriety as Agile has become more widespread. These include waning sponsor engagement and support over time; insufficient training; teams are not focused (they are either under or over scheduled-either of which can cause a loss of focus); and disciplined use of fixed time, resources and scope.

A broader perspective of Agile can connect its roots to some of the principles of lean methodology: every action should have value. Unlike Agile, however, lean developed a number of measurable outcomes and could test before and after scenarios to indicate the quality of improvement. A more “rough and ready” attitude among those embracing Agile, the four values and sprint developments aim to “fail early and fail often, to avoid a disaster at the end.” This view of development has been expressed more succinctly in the noted acronym PDCA (Plan-Do-Check-Adjust).

Regardless of how strongly this or other methodologies are embraced, Agile makes a set of assumptions that are a fundamental blind spot not just for Agile, but for any formal process. This weakness comes from the belief that the execution will be done “perfectly.” If we take a look at the first Agile value, which states individuals and interaction are valued over processes and tools, it assumes the individuals and interactions proceed in a nearly perfect way and that the processes and tools are somehow not quite as capable of moving the project along. One never does get to re-run a specific software development project over again using different techniques to test the Agile process against any other. Because of this, the successes, or not, of Agile methodologies are necessarily anecdotal in nature. It has its detractors as well as its supporters.

One thing is certain, though. Agile began an outpouring of people, companies and techniques to improve the difficult task of corralling software development. This speaks more to the idea that Agile is not so much a one-size-fits-all solution as much as an industry catalyst that was ripe for a change to development processes. And even though Agile may not be the solution to every problem, certain aspects, like improved communication, and testing snippets of software along the way are probably a good idea.

Out of necessity this can only be a top-level view of Agile development. There is a forest of acronyms, processes and jargon that has grown around the Agile “seed.” If you have heard of Scrum, User Stories, Kanban and Refactoring code, you are looking at the offspring of both Lean and Agile methodologies. Whether you adopt Agile or not, it’s clear that any system only works as long as all of the players know their roles and there is a steadfast commitment from the first meeting to the delivered working prototype from all of the people involved.

About the author

Scott Orlosky has an MS in Manufacturing and Control Theory from the University of California at Berkeley and has worked over 30 years designing, developing, marketing and selling sensors and actuators for industrial and commercial industries. He has written numerous articles and application notes for speed and position sensors used in industrial and hazardous area environments including an author credit in “Encoders for Dummies.” Scott authored an industrial newsletter for nearly 15 years and is also co-inventor on a number of patents involving design and manufacturing of inertial sensors.