Process Improvement: Intro to Agile

The high-tech industry has followed a proven method of product management that works quite nicely in a number of industries for everything from hydrophilic guide-wires to notebook computers to refrigerators—plan, develop, launch, EOL. When the product leaves the planning stage, it is pretty well defined. It gets on the POR and roadmaps are created. MRDs, PRDs are written: It is built and launched. It’s a pretty simple paradigm. But what if the product has characteristics that require it to change during the development process? What if there is a need for continual customer feedback as the product moves forward through the development cycle? The traditional “HW model” doesn’t work. This is where Agile has earned its stripes.

Agile assumes that the group is more powerful than the individual; consequently, there are small groups created to work together to address changing “customer requirements” and functionality ideas. It used to be that a single programmer would write their own code and submit it for testing. On a large project, there could be an enormous amount of duplicate code written by each programmer. Agile promotes leveraging resources. With Agile, groups own a part of the whole project. There is minimal duplication of effort. When a group has completed their part, the result is fully functional and can be part of a release. Also, there are parts of the application that are functioning at different times in the project’s development, Agile encourages getting the customer involved as pieces are available to evaluate. The customer can then provide timely feedback at a time when before the product has been announced. Progress is measured not by milestone achievement, but as a percent of the product completed. This is a fundamental difference. With a physical product, televisions, for instance, just because the injection molding is done, you can’t claim to have 20% of a TV to ship to a customer.

Agile provides the flexibility for software developers to continually change the functionality of their products. So, what does this mean to the PM? It makes a very challenging work environment if you want to communicate what your product can do. You have to be able to do the following:

  • As flexible as the paradigm.
  • To be able to update your deliverables as you find out about more releases.
  • Continually update your internal and external customers.
  • Maintain most of your deliverables in electronic form—too expensive to create hard-copy as functionality changes.
  • Choose how often to approach the analysts/trade press—too many communications creates an impression that you don’t have a clear direction or an ill-defined strategy.

This is why software (apps, tools and operating systems) cause so much concern in the eyes of the consumer. How many times have you updated you Windows operating system only to find out that you don’t have the correct drivers, release of your other applications or, worse yet, none of your favorite applications or devices work anymore? I have thousands invested in printers and scanners that won’t work with Vista and the peripheral manufacturer has chosen not to re-write the driver to support Vista! As a customer of software, any change is met with serious caution. I don’t think my perception is unique. As a PM, what do you do with this information? Actually, you wouldn’t know or have visibility to the information because it resides in the development group until it makes a decision. In Agile, the ownership of the product resides with the developers, not the Product group. If you were to contrast this with the traditional model, you would know at the front-end that this would happen because product definition and customer research occurs there. Also, the earlier in the cycle you know customer needs, the less wasted time and money on projects that are problematic.

There is a very good article written by Don Wells called “Agile Software Development: A gentle introduction” in which he details the methodology and reasoning behind Agile for software development. As a PM, however, your customers want to know what they can buy and when. If the product keeps changing, your job can be quite difficult. You might want to have a “stake put in the ground” so that you have something concrete on which to base an announcement. Anything after a certain date, for example, will have to wait for the next announcement. Keep in mind that launching a product is a project with definite milestones. It is in stark contrast with the Agile model that doesn’t.

Leave a Reply

Please log in using one of these methods to post your comment: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: